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ABSTRACT 


The  thesis  presents  the  concept  and  development  of  a 
diagnostic  decision  support  system  for  real-time  control  and 
automation  of  dynamic  processes.  This  system,  known  as  DECA 
(Diagnostic  Evaluation  and  Corrective  Action),  will  take 
advantage  of  the  computer’s  ability  to  manipulate  vast 
amounts  of  data,  and  employ  qualitative  reasoning  for  the 
monitoring  and  diagnosis  of  dynamical  processes  during 
time-constrained,  routine,  and  emergency  situations  where  an 
immediate  response  is  necessary  to  avoid  catastrophic 
failure  of  the  system. 

The  software  system’s  architecture  has  been  structured 
in  such  a  manner  that  it  can  be  applied  to  any  dynamic 
process  without  reprogramming.  DECA  is  written  in  Lisp  and 
was  verified  using  the  data  from  the  Three  Mile  Island 
Nuclear  Reactor  Accident. 
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Chapter  1 
Introduction 

Expert  Systems  have  been  proclaimed  as  the  panacea  for 
Industry’s  problems  in  recent  years.  They  are  said  to 
incorporate  vast  amounts  of  knowledge,  learn  and  use  this 
knowledge,  all  in  a  broad  domain.  While  in  the  realm  of 
implementations,  the  past  history  shows  that  the  most  useful 
Expert  Systems  have  been  applied  to  a  specific  domain  to 
carry  out  a  set  of  specific  tasks.  Some  examples  of 
successful  Expert  Systems  are  MYCIN  [Bucha84]  and  R1 
[McDer82].  In  the  realm  of  real-time  processing,  some 
successful  Expert  Systems  are  Picon  [Leinw87],  Falcon 
[Shirl87],  and  Ecesis  [Dicke84].  The  reason  for  their 
success  is  that  they  have  a  workable  size  knowledge  base  and 
the  complex  interactions  are  not  beyond  the  computational 
power  currently  available. 

1 . 1  Motivation 

The  advent  of  powerful  computers  has  created  useful 
applications  for  dynamic  control.  The  computer’s  ability  to 
handle  vast  amounts  of  information  efficiently  makes  it 
ideal  for  monitoring  large  dynamical  systems. 

Earlier  work  has  been  in  the  area  of  dynamic 
programming,  where  the  globally  optimal  solution  to  the 
problem  is  used.  As  the  system’s  complexity  increases  in  the 
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number  of  parameters,  processing  time  required  to  *ind  the 
optimal  solution  increases  exponentially.  The  increased 
processing  time  required  makes  the  dynamic  processing 
methods  impractical  for  dynamic  process  control  or 
monitoring  systems  in  real-time. 

Previous  research  concentrated  on  developing  a  locally 
optimal  solution  which  will  enable  the  real-time  monitoring 
of  dynamic  processes.  Jow’s  work  [Jow84]  in  the 
implementation  of  the  CKW  local  optimization  algorithm 
(appendix  C)  makes  real-time  monitoring  of  many  parameters 
in  a  complex  dynamic  process  feasible. 

In  recent  years,  with  the  development  of  efficient 
computers  for  running  Artificial  Intelligence  (AI) 
applications,  the  development  of  AI  based  applications  for 
monitoring  and  control  of  complex  dynamic  processes  in 
real-time  has  become  a  possibility.  This  thesis  explores  one 
possible  way  to  monitor  these  dynamic  systems  using  AI  and 
Expert  System  techniques.  It  builds  upon  Jow’s  work,  but 
instead  of  an  algorithmic  approach,  it  uses  qualitative 
reasoning.  This  thesis  uses  some  of  the  fundamental  notions 
of  Milne’s  theory  of  diagnosis  [Milne87]. 

1.2  The  DECA  System 

In  this  thesis,  the  domain  of  dynamical  processes  is 
considered  as  a  candidate  for  real-time  monitoring  and 
information  prioritization.  If  the  common  elements  of  all 
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dynamical  processes  are  focused  upon,  it  appears  feasible  to 
be  able  to  develop  a  generic  Expert  System  that  can  be  used 
with  these  various  systems.  The  outcome  is  expected  to  be 
largely  similar  to  the  project  presented  here;  DECA, 
Diagnostic  Evaluation  and  Corrective  Action.  DECA  is 
designed  to  implement  a  control  strategy  for  dynamical 
processes  during  routine,  time-constrained,  and  emergency 
situations.  The  goal  is  to  develop  DECA  into  a  general 
purpose  shell  which  would  be  versatile  and  sufficiently 
autonomous  in  the  sense  that  it  would  be  capable  of  handling 
the  computer  operational  details  and  execute  the  processes 
in  real-time  while  the  human  user  would  concentrate  on 
setting  up  the  knowledge  base  for  the  particular  application 
at  hand.  DECA  can  be  interfaced  with  simulators  or  with  the 
plant  under  control.  The  major  objective  of  DECA  is  to 
support  human  operators  in  the  decision  making  process.  In 
the  hierarchical  decision  structure,  DECA  will  function  less 
autonomously  at  higher  levels. 

1.3  Overview  of  DECA 

The  system  is  a  multi-stage  one.  Given  the  current 
state  of  the  system,  in  real  time,  DECA  tries  to  diagnose 
the  causes  for  any  malfunction,  based  on  qualitative 
reasoning  [DeKle83],  At  the  lower  level,  for  the  given 
diagnosis,  DECA  tries  to  identify  the  relevant  variables 
along  with  more  detailed  analysis  of  the  current  state  so 


that  any  impending  disaster  can  be  avoided  by  effectively 
implementing  a  set  of  corrective  actions. 

There  are  three  main  levels  in  the  DECA  system: 

Di agnost i c- 1 ,  the  Classifier;  the  Prioritizer;  and 
Diagnostic-2,  the  Corrective  Action  implementor.  Figure  1.1 
shows  the  system  structure.  Chapter  3  gives  a  detailed 
process  flow  diagram  and  explanation  of  the  system. 


Figure  1.1  Overview  of  DECA  System 

In  the  first  level,  the  Classifier,  DECA  reads  the  input 
data,  determines  what  parameters  are  beyond  normal  operation 
and  their  severity.  The  second  stage,  the  Prioritizer, 
evaluates  the  parameters  and  finds  their  importance  as  well 
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as  searches  the  database  for  possible  disaster  scenarios. 

The  third  stage,  Corrective  Action,  pulls  together  the 
parameter  priority,  scenario  likelihood  and  determines  the 
cause  of  the  emergency.  Once  the  scenario  is  selected,  it 
searches  its  knowledge  base  for  a  likely  solution  or  action 
for  the  operator  to  implement. 

1.4  Areas  of  Application 

DECA  is  particularly  suitable  for  dynamical  systems 
where  many  parameters  need  to  be  monitored  continuously.  For 
example,  the  Space  Station  will  need  constant  monitoring  of 
its  vibrational  characteristics  and  stability  [Firsc86, 
Ray87].  Another  area  of  application  is  the  control  of 
advanced  fighter  aircraft  [Ander84,  Pisan84].  While  in  a 
combat  situation,  the  pilot  not  only  has  to  fly  the  plane, 
but  also  has  to  keep  track  of  the  weapons  systems  and 
targets.  An  Expert  System  can  be  used  to  monitor  all  the 
rudimentary  lower  level  controls,  allowing  the  pilot  to 
concentrate  on  the  immediate  danger  at  hand  -  the  enemy. 
Chemical  and  nuclear  processes  can  also  benefit  from  DECA  in 
a  simi lar  way. 

The  system’s  control  process  can  be  invoked  via  manual 
intervention  or  through  an  automatic  mode.  In  the  former 
case,  the  diagnostic  system  will  serve  as  an  overall 
advisor.  In  the  latter  case,  it,  by  virtue  of  proper 
interfaces  would  be  able  to  control  the  process.  For 
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example,  a  space  probe  in  the  outer  reaches  of  the  solar 
system  would  be  able  to  take  some  emergency  actions  to 
preserve  itself. 

1.5  Application  to  Evaluate  System 

The  general  framework  of  DECA  and  its  efficacy  have 
been  tested  using  real  world  problem  of  the  Three  Mile 
Island  nuclear  power  plant  number  2  (TMI-2)  accident.  This 
particular  example  was  considered  due  to  the  availability  of 
data  and  earlier  reports  [NSAC-1,  NSAC-1S]  which  can  be  used 
for  evaluating  the  performance  of  DECA. 

The  main  problem  which  plagued  the  accident  was 
information  overload.  Studies  have  shown  that  the  average 
human  can  handle  about  seven  pieces  of  information  before 
reaching  information  overload  [Mille56].  This  is  exactly 
what  happened  at  TMI .  The  reactor  shut  itself  down  after  a 
turbine  tripped,  and  soon  after,  a  block  valve  opened  and 
stuck  open  on  the  primary  cooling  system.  With  the  draining 
of  primary  coolant  and  other  events  going  on,  the  number  of 
alarms  that  were  being  tripped  in  the  control  room  caused 
the  operators  to  overlook  the  real  culprit  -  the  stuck  block 
valve.  It  was  not  discovered  for  over  two  hours,  after  the 
damage  was  done. 

DECA  could  have  been  of  value  in  TMI  because  it  has  the 
capability  to  keep  track  of  many  parameters,  figure  out 
which  are  the  most  critical,  and  take  corrective  action  or 
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give  the  operator  a  summary  of  its  knowledge.  With  this 
knowledge,  the  operators  will  be  able  to  solve  the  root  of 
the  problem  and  the  side  effects  will  resolve  themselves. 

1.6  Contribution  of  the  Thesis 

The  objective  of  this  thesis  is  to  develop  a  kernel  of 
a  future  Expert  System  for  autonomous  dynamical  process 
control.  As  it  is  refined,  more  capabilities  will  be  added 
to  enable  it  to  automatically  control  a  simulated  or 
physical  system.  In  its  current  stage  of  development,  DECA 
plays  the  role  of  an  advisor  to  the  system  operators. 

This  thesis  demonstrates  an  inference  engine  that  can 
be  used  for  the  automation  of  monitoring  dynamical  processes 
in  real-time.  The  contribution  of  the  DECA  system  is  as 
f ol 1 ows : 

1- Develop  and  implement  a  new  architecture  specifically 
designed  to  automate  the  monitoring  and  control  of 
dynamical  processes. 

2- The  capability  to  run  in  real-time. 

3- Develop  the  system’s  diagnostic  capabilities  to 
utilize  qualitative  reasoning. 

4- Give  DECA  the  ability  to  integrate  analytical  models 
along  with  the  qualitative  models. 
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5- Keep  the  system  modular  to  enhance  software 
maintenance . 

6- Develop  the  system  in  such  a  manner  to  insure 
portabi 1 i ty. 

1.7  Implementation  of  DECA 

DECA  is  being  implemented  on  a  Symbolics  3670  using 
common  LISP  in  conjunction  with  Flavors  [WeinrSO]. 

Currently,  the  system  development  uses  the  Three  Mile  Island 
reactor  accident  data.  However,  the  framework  of  DECA  is 
general  enough  to  be  applied  to  a  variety  of  dynamic  control 
situations. 

1.8  Organization  of  Thesis 

This  thesis  consists  of  seven  chapters,  a  list  of 
references,  and  six  appendices. 

Chapter  2  discusses  theoretical  issues  and  draws 
parallelisms  to  Milne’s  theory  of  diagnostics.  In  chapter  3, 
a  detailed  description  of  DECA’s  structure  is  given  and  a 
discussion  of  the  inference  engine  is  located  in  chapter  4. 
Chapter  5  provides  the  details  of  developing  the  DECA 
program  on  the  Symbolics  computer.  Chapter  6  reviews  and 
discusses  the  results  from  the  test  runs  of  the  software  and 
draws  conclusions  about  the  system.  In  chapter  7,  the  goals 
of  future  research  are  given. 
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A  list  of  the  references  is  provided  after  chapter  7. 
Appendix  A  provides  background  information  about  the  System 
Query  Language.  Additional  background  information  is  given 
in  appendix  B  and  C.  Appendix  B  describes  the  control 
strategies  in  MYCIN,  while  appendix  C  discusses  the  CKW 
algorithm  for  the  local  optimization  of  systems  in  real 
time.  Appendix  D  consists  of  the  data  from  the  execution  of 
the  DECA  program  for  the  test  run  and  for  the  Three  Mile 
Island  Reactor  Accident.  Appendix  E  describes  the  knowledge 
base  for  the  Three  Mile  Island  Reactor  and  gives  listings  of 
the  files  which  contain  the  data.  Finally,  appendix  F  gives 
the  listing  of  the  DECA  program. 
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Chapter  2 

Milne’s  Theory  of  Diagnosis 

In  recent  years  there  has  been  a  tremendous  leap 
forward  in  technology  leading  to  new  applications  of 
Artificial  Intelligence  and  Expert  Systems,  especially  in 
the  area  of  diagnostics.  According  to  Milne  [Milne87], 
there  are  many  new  techniques  available  giving  us  the 
ability  to  build  and  reason  about  models  dealing  with  a 
large  domain  of  information  (e.g.  learning  from  experience, 
probabilistic  information,  and  learning  from  examples).  The 
DECA  system’s  architecture  in  many  respects,  parallels 
Milne’s  concept  of  diagnostics  and  reasoning. 

2.1  Levels  of  Diagnosis 

In  a  diagnostic  system,  the  key  to  a  successful 
implementation  is  through  the  system’s  ability  to  be 
flexible  in  its  interface  with  the  physical  system.  The 
ability  to  accept  input  data  in  a  format  or  description  that 
is  most  logical  with  a  particular  domain  is  also  critical 
for  a  successful  implementation. 

The  manner  in  which  Milne  creates  this  is  by  having  a 
network  of  different  levels  which  can  readily  pass  data 
between  one  another  giving  it  modularity.  This  flexibility 
makes  the  approach  "generic",  and  usable,  for  a  wide  variety 
of  diagnostic  applications. 


In  the  subsequent  discussion  Milne’s  framework  is 
explained  and  its  parallel  with  DECA  is  illustrated. 

In  Milne’s  diagnostic  scheme  [Milne87]  there  are  four 
levels  that  are  layered  together.  They  are: 

1  -  Structural 

2  -  Behavioral 

3  -  Functional 

4  -  Pattern  Matching 

The  four  levels  are  connected  together  serially  1-2-3-4,  and 
each  level  has  both  input  and  output.  With  this  setup,  one 
"can  build  a  diagnostic  system  based  on  knowledge  which  has 
been  input  at  any  level  and  stop  at  any  level”  [Milne87  p. 
334].  Figure  2.1  graphically  depicts  the  i nterrel ati onshi ps 
between  the  levels  and  system  input/output  (i/o). 

In  the  first  level  of  diagnosis,  the  system  uses  the 
knowledge  about  the  system  structure  for  diagnosis.  The 
system  contains  a  small  number  of  hypotheses  of  what  is 
wrong.  It  will  derive  tests  to  discriminate  between  the 
hypotheses.  In  the  structural  level  the  expert  system  uses 
the  structural  knowledge  about  the  process  and  system  to 
simulate  possible  faults  and  compare  the  results  to  an 
on-line  library.  From  the  results  of  the  simulation,  it  will 
use  forward  reasoning  to  qualitatively  select  the  proper 
diagnosis.  The  qualitative  reasoning  capability  is  not 
extensive  in  the  first  stage,  and  the  depth  of  knowledge 
about  the  system  is  generalized.  Since  this  is  not  an 
extensive  model  of  the  systems,  a  diagnostic  system  using 
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only  the  first  stage  is  called  a  "shallow"  knowledge 
system. 

The  second  stage  of  Milne’s  diagnostic  architecture  is 
the  behavioral  stage.  It  performs  the  following  function: 
"Given  a  representat i on  of  the  behavior  of  components  of  the 
devices,  system,  and  a  representation  of  the  components,  the 
ability  to  generate  the  behavioral  description  of  the  device 
as  a  whole  is  an  important  part  of  causal  reasoning” 

[Milne87,  p.  83].  In  the  second  stage  the  reasoning  becomes 
much  more  complex  than  in  the  first.  There  are  two  methods 
to  carry  out  the  reasoning:  qualitative  simulation,  and  the 
consolidation  method  [Dekle83], 

In  general,  for  the  diagnosis  of  a  simple  system,  only 
the  first  two  stages  are  needed.  They  give  a  fragmented 
evaluation  of  the  interrelationships  of  the  devices  in  a 
larger  system.  If  the  application  is  a  very  complex  system, 
there  will  likely  be  a  need  to  tie  together  the  fragmented 
information  in  a  hierarchical  structure.  On  a  large  system 
one  "can  often  put  together  function  of  the  device  and 
relationship  to  its  structure"  [Milne87,  p.  334]  using  the 
two  lowest  levels. 
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Shallow  Assertions  Rule  Based 


Figure  2.1  Milne’s  Levels  of  Diagnostic 
Reasoning  [Milne87,  p.  334] 
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The  third  stage  is  the  functional  level.  Sometimes  the 
knowledge  deduced  by  the  first  two  stages  is  enough  to 
diagnose  a  problem  in  a  device  of  the  system,  but  not  the 
complete  evaluation  of  the  whole  system.  To  perform  a 
diagnosis  it  may  be  necessary  to  have  the  behavior  of  the 
device  go  through  an  abstraction  to  a  higher  level  of 
knowledge  representation .  The  higher  level  generally  relates 
the  interactions  between  function  and  structure.  It  can  also 
be  patterned  into  a  hierarchy  of  the  interrelationships 
between  the  devices  in  the  system. 

The  fourth  stage  is  what  Milne  refers  to  as  the  "Deep 
Function  Model-Based  Diagnosis  System"  [Milne87,  p.  335]. 
Taking  the  model  and  having  a  knowledge  representation  to 
relate  function,  behavior,  and  structure,  it  can  perform  the 
top-level  pattern-matching. 

The  deep  function  model-based  diagnostic  system  would 
enable  the  information  to  enter  at  any  of  the  four  levels, 
utilize  the  strengths  of  one  or  more  level  and  exit  at  any 
level.  This  would  basically  yield  any  of  four  types  of 
diagnostic  systems  available. 

2.2  Correlation  Between  Milne’s  Levels  and  DECA 

Milne’s  frame  work  forms  the  basis  for  DECA’s 
archi tecture .  Referring  to  figure  2.1,  it  is  apparent  that 
DECA  employs  the  concepts  of  Milne’s  first  three  levels, 
Structure,  Behavior,  and  Function.  Essentially  the 
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correlation  between  DECA  and  Milne  is  as  follows;  DECA’s 
Classifier  is  the  same  as  Milne’s  Structure,  Prioritizer  is 
equivalent  to  the  Behavior,  and  the  Corrective  Action  module 
is  equivalent  to  Milne’s  Function  level. 

The  Classifier  uses  the  system  structure  to  determine 
where  the  problems  are  arising  on  a  subsystem  level,  and 
selecting  general  scenarios  which  may  be  feasible.  It  then 
feeds  this  data  to  the  Prioritizer. 

The  Prioritizer  section  correlates  well  with  Milne’s 
Behavior  level,  for  the  Prioritizer  decides  which  parameters 
are  the  most  critical  from  the  data  given  to  it  about  the 
system.  It  also  takes  into  account  the  interactions  of  the 
elements  of  the  system  and  general  tendencies  of  the 
system’s  components  under  a  given  condition.  The  Prioritizer 
will  determine  the  priority  of  the  system  parameters  and 
select  a  few  most  likely  scenarios  as  to  what  the 
malfunction  is. 

The  Corrective  Action  segment  of  the  DECA’s  inference 
engine  closely  correlates  with  Milne’s  Function  layer.  The 
duty  of  the  corrective  action  layer  is  to  determine  which  of 
the  scenarios  chosen  by  the  Prioritizer  is  the  actual  system 
malfunction  and  then  figure  out  what  would  be  the  best 
remedy  to  implement.  In  the  event  that  DECA  cannot  find  a 
solution,  the  Corrective  Action  segment  will  give  the 
operator  a  list  of  the  parameter  priorities  and  a  brief 
description  of  which  part  of  the  system  he  should 
concentrate  his  efforts  on. 
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In  summary,  one  can  see  that  DECA’s  structure  closely 
parallels  Milne’s.  DECA’s  ability  to  adapt  its  structure 
and  internal  function,  and  its  modularity  make  it  feasible 
to  be  implemented  in  a  variety  of  applications  in  automatic 
diagnosis  and  control  for  dynamical  systems. 


Chapter  3 

Detailed  Description  of  the  DECA  Kernel 
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This  chapter  gives  a  detailed  description  of  DECA’s 
internal  architecture  and  process  flow.  An  overview  of  the 
major  components  of  DECA  are  discussed  in  section  1.3. 

3.1  Design  Goals  for  DECA 

When  the  DECA  architecture  was  developed,  the  following 
objectives  were  incorporated  into  the  system.  They  are: 

1-  For  DECA  to  monitor  many  parameters  in  a  real-time 
fashion . 

2-  The  ability  to  quickly  separate  all  relevant  data 
from  extraneous  information. 

3-  Diagnose  the  system’s  malfunction/abnormality,  and 
if  not  possible 

4-  Output  the  relevant  parameters  and  their  priority  in 
order  to  focus  the  operator’s  attentions  to  the  part  of 
the  system  which  the  problem  emanates  from,  thus 
eliminate  side  effect  distractions. 


3.2  Process  Flow  Chart 

Figure  3.1,  contains  a  detailed  process  flow  diagram  of 
the  DECA  system.  In  subsequent  discussion,  a  detailed 
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explanation  of  DECA  kernel  is  given. 

From  the  DECA  process  flow,  it  can  be  seen  that  the 
knowledge  bases  for  the  application  problem  have  been  kept 
separate  from  the  inference  engine.  This  has  been  done  for 
two  reasons.  First,  keeping  the  domain  data  in  a  separate 
database  enables  the  operator  to  easily  update  the  system  to 
represent  any  changes  in  the  physical  system.  Secondly,  with 
a  separate  inference  engine,  DECA  can  be  adapted  to  a  great 
many  different  dynamical  processes.  Only  the  domain 
knowledge  needs  to  be  incorporated  for  each  new 
appl i cation . 

The  modular  structure  will  also  help  improve  DECA’s 
versatility,  for  the  reference  databases  need  only  be 
changed  when  DECA  is  applied  to  another  problem  domain. 

Also,  DECA  can  be  modified  to  run  subroutines  instead  of 
referencing  data  in  certain  databases.  For  example,  DECA  can 
be  told  to  access  an  analytical  model  or  run  a  simulation 
for  retrieving  setpoint  data  instead  of  looking  up  a  data 
table.  It  can  interact  with  its  databases,  analytical 
models  and  simulation  modules  in  a  coherent  manner.  The  data 
and  subroutines  do  not  even  have  to  be  resident  in  the  same 
computer,  enabling  DECA  to  use  distributed  computing 
techniques.  This  also  allows  DECA  to  take  advantage  of 
previous  information  without  recoding  it. 

The  following  pages  deal  with  the  detailed  analysis  of 
the  DECA  kernel.  Figure  3.1  contains  the  flowchart  for 
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Fig.  3. t  continued 
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Sort  the  parameters  that 
are  oob  by  priority 
number.  Store  the 
results . 


Sorted  oob 
parameters 


IF  any 

parameters  have^ 
same  priority/' 
x.  number  / 


Rank  the 
parameters 
with  a  higher 
severity  first. 
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scenarios. 
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Store  results. 
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ranking  of  the  parameters 
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fits  best  with 
expected  results). 
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database  (sorted) 
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1  continued 


Fig.  3.1  continued 


3.3  System  Inputs 


The  input  to  the  system  is  through  on  line  sensors.  For 
the  example  run  of  Three  Mile  Island  Unit  Two  (TMI-2)  there 
are  nine  parameters. 


PZR-P 

Pressurizer  Pressure 

psig 

PZR-L 

Pressurizer  Level 

inches 

HL1-T 

Hot  Leg  Temperature 

deg  F 

CL1-T 

Cold  Leg  Temperature 

psig 

SGI  -P 

Steam 

Generator  #1  Pressure 

inches 

SGI  -L 

Steam 

Generator  #1  Level 

psig 

SG2-P 

Steam 

Generator  #2  Pressure 

psig 

SG2-L 

Steam 

Generator  #2  Level 

inches 

QNT-P 

Drain 

Tank  Pressure 

deg  F 

The  data  comes  into  the  system  in  a  set  order  known  a 
priori.  That  is,  we  assume  that  the  control  processor 
gathers  the  data,  checks  the  accuracy  and  validity  of  the 
data  and  sends  out  a  stream  of  numbers.  Since  the  data  has 
been  authenticated  by  the  instrumentation,  DECA  assumes  that 
the  data  is  accurate  through  the  instrumentation’s  use  of 


fault  detection  and  verification. 
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3.3.1  On-Line  Information 


As  the  sensor  data  is  read  into  DECA,  it  is  stored  in 
an  On-line  Information  database  (OLI).  Table  3.1  shows  a 
sample  of  the  OLI  database  for  time  period  0  to  tx. 


Table  3.1  On-line  Information  Database 


ORDER 

PZR-P 

PZR-L 

HL1-T 

SGI  -P 

SGI  -L 

SG2-P 

SG2-L 

QNT-P 

CL1-T 

0 

2145 

218 

607 

944 

123 

3 

930 

116 

559 

15 

2260 

253 

611 

1022 

79 

6.3 

1012 

80 

571 

30 

1905 

182 

587 

998 

26 

7.8 

987 

30 

577 

45 

1855 

160 

579 

1000 

17 

9.3 

993 

20 

576 

60 

1  790 

158 

578 

990 

14 

12 

969 

18 

576 

75 

1760 

1  pp 

577 

101  1 

10 

14.3 

997 

16 

576 

90 

1725 

1  ~  i> 

578 

1023 

1  1 

17.5 

1005 

16 

577 

105 

1685 

187 

579 

1021 

1  1 

19.6 

1005 

16 

577 

120 

• 

1650 

200 

• 

579 

• 

101  1 

• 

1  1 

• 

22.2 

• 

1000 

• 

16 

• 

579 

• 

• 

tx 

" 

• 

•  • 

data  for 

• 

time 

• 

x 

• 

• 

• 

0,  15,  30,..., tx  is  the  index  for  OLI.  For  our  example,  the 
values  of  tx  will  correlate  to  the  time  intervals  during  the 
TMI-2  accident.  Even  though  we  will  only  be  concerned  with 
the  present  record  (or  data  sample  for  a  given  time),  having 
the  history  will  enable  DECA  to  determine  the  relative 
speeds  of  the  transients  which  will  contribute  information 
towards  qualitatively  deducing  an  urgency  for  various 


parameters . 
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3.3.2  Setpoint  Database 

Processing  of  information  will  begin  once  the  OLI 
database  has  been  established.  First  it  takes  a  record  t 

n 

which  corresponds  to  the  data  at  the  instant  of  time  under 
investigation  (usually  the  most  recent),  and  checks  each 
parameter  against  the  setpoints  for  normal  operation.  For 
normal  reactor  operation  the  relational  data  base  for 
setpoints  (SDB)  is  as  follows  [Jow84,  p.  5-13]: 

Table  3.2  Setpoint  Database  (SDB) 


VARIABLE 

LLL 

LL 

PZR-P 

1200 

1900 

PZR-L 

45 

150 

HL1-T 

300 

400 

SGI  -P 

800 

850 

SGI  -  L 

10 

30 

QNT-P 

1 

2 

SG2-P 

800 

850 

SG2-L 

10 

30 

CL1-T 

300 

400 

1 _ N _ H 


2055 

2150 

2250 

200 

222 

240 

500 

606 

610 

900 

940 

1050 

45 

160 

170 

2.5 

3 

35 

900 

940 

1050 

45 

160 

170 

500 

558 

610 

HH 

HHH 

UNITS 

2355 

2400 

psig 

260 

280 

inches 

619 

630 

deg  F 

1070 

1105 

psig 

180 

190 

i nches 

80 

122 

psig 

1070 

1105 

psig 

180 

190 

i nches 

619 

630 

deg  F 

The  versatility  of  the  system  can  be  enhanced  by  utilizing 
DECA’s  ability  to  access  different  setpoint  databases.  When 
DECA  looks  at  a  setpoint  database,  it  must  check  a  system 
flag  to  determine  where  to  look  for  the  data.  The  system 
flag  is  set  from  an  external  source,  such  as  data 
acquisition  equipment  or  from  the  operator’s  console.  The 
value  of  the  flag  reflects  the  present  state  of  operation 
the  system  is  in  (e.g.  normal,  reactor  shutdown,  etc.).  For 


28 


example,  the  database  shown  above  (Table  3.2)  is  for  normal 
operating  mode.  If  the  reactor  were  to  be  shut  down  or 
reduce  power  output,  there  would  be  some  transients  which 
are  normal  to  this  action,  but  DECA  would  trigger  alarms 
because  some  values  are  indicated  as  being  out  of  bounds. 
With  the  flag  set,  DECA  will  be  directed  to  look  at  a 
shutdown  database,  or  it  will  be  directed  to  call  a 
subroutine  which  contains  an  analytical  model  to  determine 
the  appropriate  setpoints  for  the  present  state  of  the 
system.  This  ability  to  switch  between  setpoint  databases 
will  alleviate  the  triggering  of  false  alarms,  thus  letting 
DECA  focus  its  attention  on  the  problem. 

3.4  Evaluating  Sensor  Data,  Diagnostic-1 

When  processing  a  record  of  parameter  values  from  the 
OLI  database,  the  system  will  take  the  parameter  data  and 
compare  it  with  its  setpoint  value.  Retrieval  of  data  in 
the  SDB  can  be  done,  uniquely  through  the  variable  name  as 
the  key.  By  comparing  the  data  against  the  setpoints,  DECA 
determines  whether  it’s  in  normal  operating  range  or  beyond 
its  normal  range.  If  it  is  normal,  the  parameter  is  left 
alone,  but  if  out  of  bounds,  DECA  will  determine  the  degree 
to  which  it  is  out  (e.g.  L,  LLL,  HH,  etc.).  This  flag  and 
correspondi ng  thresholds  indicate  the  severity  associated 
with  the  system  parameters.  Also,  DECA  can  incorporate 
fuzzy  set  theory  into  the  system,  and  the  degree  to  which 
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each  parameter  is  bound  can  be  more  accurately  determined. 
For  example,  if  a  parameter  has  a  severity  of  H  (for  High), 
then  employing  a  blending  function  [Zadeh65,  86]  can  assign 
a  value  indicating  the  degree  of  membership.  For  example, 
0.25  would  indicate  that  it  is  only  slightly  over  the  High 
threshold.  This  degree  of  membership  is  loosely  analogous 
to  its  "percentage  of  highness",  but  is  an  excellent  way  of 
quantifying  the  abstract. 

There  are  several  ways  in  which  the  comparison  of 
parameter  data  and  setpoint  data  can  be  retrieved  and 
analyzed.  This  versatility  is  necessary  to  keep  DECA  in  a 
generic  format  enabling  it  to  be  used  in  a  variety  of 
dynamic  processes.  As  an  illustration,  for  the  first  part  of 
the  monitoring,  DECA  takes  the  sensor  data  and  compares  it 
to  the  values  in  the  setpoint  database  to  determine  if  the 
parameters  are  out  of  bounds.  The  system  uses  two  rules 
which  would  be  applied  to  each  of  the  system  parameters. 

Rule  one:  read  the  value  of  the  parameter  and  compare 
it  to  the  values  for  H  and  L  in  the  SDB.  If  the  parameter 
is  greater  than  H  or  if  the  parameter  is  less  than  L  tag  the 
parameter  as  being  out  of  bounds. 

Rule  two:  if  the  parameter  is  flagged  as  being  out  of 
bounds,  then  compare  it  to  the  SDB  values  for  LLL ,  LL,  L,  H, 
HH,  HHH  and  determine  which  range  they  fall  in.  This  range 
(e.g.  LL)  will  be  used  as  the  severity  of  out  of  bounds. 

In  an  algorithmic  fashion,  the  rules  would  be  as 


fol lows: 
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Rule  1:  Read  the  value  of  the  parameter  :=  PI; 

Call  procedure  comparison; 

Procedure  comparison; 

Retrieve  SDB; 
if  PI  >  H  and 
PI  <  L 

out  of  bounds  =  true; 
return ; 

Rule  2:  Read  the  value  of  the  parameter 
which  is  out  of  bounds  :=  PI; 

Call  procedure  comparison; 

Procedure  comparison; 

Retrieve  SDB; 

If  PI  is  in  range 
LLL  to  L  or 
H  to  HHH 

Severity  :=  LLL,  LL,  L, 

H,  HH,  HHH; 

return ; 

Also,  if  most  of  the  setpoint  data  was  stored  in  a 

typical  relational  database,  one  could  use  SQL  data 

retrieval  language  to  access  the  data  (see  appendix  A  for 

detailed  description  of  SQL).  The  rules  necessary  to 

compare  the  data  are  shown  below  in  the  SQL  format.  These 

rules  would  be  applied  to  each  of  the  monitored  parameters 

of  the  system. 

Rule  to  flag  a  parameter: 

SELECT  TIME,  VARIABLE,  PARAM 
FROM  OLI 
WHERE  PARAM  IN 
SELECT  * 

FROM  SDB 

GROUP  BY  VARIABLE 
HAVING  PARAM  <  L 
OR  PARAM  >  H 

Rule  to  assign  the  severity: 

CREATE  TIME,  VARIABLE,  PARAM,  SEVERITY 
FROM  OLI 
WHERE  PARAM  IN 
SELECT  PI,  * 
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FROM  SOB 
GROUP  BY  VARIABLE 
HAVING  PI  <  LLL 

CREATE  PI,  SEVERITY::’ LLL  ’ 


OR 

PI  >  LLL 

AND  PI  <  LL 

CREATE  PI , 

SEVERITY= ’ LL ’ 

OR 

PI  >  LL 

AND  PI  <  L 

CREATE  PI , 

SEVERITY::  ’  L  ’ 

OR 

PI  >  H 

AND  PI  <  HH 

CREATE  PI , 

SEVERITY::  ’  H  ’ 

OR 

PI  >  HH 

AND  PI  <  HHH 

CREATE  PI , 

SEVERITY= ’ HH ’ 

OR 

PI  >  HHH 

CREATE  PI , 

SEVERITY= ’ HHH 

All  the  data  values  are  retrieved  from  the  setpoint  database 
( SDB )  and  the  on-line  information  database  (OLI),  and 
reference  the  current  time  frame  the  system  is  monitoring. 

Taking  a  rule-based  approach  more  analogous  to  a 
structured  programming  language,  some  of  the  comparison 
rules  would  look  more  like  the  following  in  the 
if . .then. .else  format: 

Rule :  Take  sensor  value  of  parameter  and  retrieve  SDB  data 
for  the  parameter 

IF  DATA  <  L  OR 
DATA  >  H 

THEN 

FLAG  PARAMETER 


The  above  rule  is  applied  to  each  parameter  in  the  OLI  data 
record.  Then  the  following  rule  will  be  applied  to  only 
those  parameters  which  are  flagged. 
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Rule  IF  flagged  THEN 

IF  data  <=  L  THEN 
IF  data  >  LL  THEN 
severity  =  L 
ELSEIF  data  >  LLL  THEN 
severity  =  LL 
ELSEIF  data  <=  LLL  THEN 
severity  =  LLL 
ENDIF 

ELSEIF  data  >=  H  THEN 
IF  data  <  HH  THEN 
severity  =  H 
ELSEIF  data  <  HHH  THEN 
severity  =  HH 
ELSEIF  data  >=  HHH  THEN 
severity  =  HHH 
ENDIF 
ENDIF 
ENDIF 

In  a  LISP  implementation  the  rules  would  be  as  follows: 


(Defun  Flag-Rule  ( parameter- looking-at) 

(Let  ((data  ( value-of-data  parameter-looking-at) ) 
(L  (value-of-SDB  Low)) 

(H  (value-of-SDB  High))) 

(cond  ((or  (<  data  L) 

( >  data  H ) ) 

( Flag-the-parameter  parameter-looking-at) ) ) ) ) 


The  rule  for  determining  severity: 


(Defun  Severity-Rule  (data  LLL  LL  L 
(Cond  ((<=  data  L) 


(Cond 

((> 

data 

LL) 

(setq 

((> 

data 

LLL) 

(setq 

((<  = 

data 

LLL) 

( setq 

( ( >=  data  H ) 

(Cond 

((< 

data 

HH) 

(setq 

((< 

data 

HHH) 

( setq 

((>  = 

data 

HHH) 

( setq 

H  HH  HHH) 

severity  L)) 
severity  LL)) 
severity  LLL)))) 

severity  H) ) 
severity  HH ) ) 
severity  HHH )))))) 


This  finishes  the  first  phase  of  the  DECA  system.  At 
this  point,  all  the  flags  have  been  set  for  the  out  of  bound 
parameters,  and  the  severity  of  out  of  boundedness  has  been 


determined . 
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3.5  DECA’s  Knowledge  Base 

Next,  the  submodules  must  be  defined  (listed  in 
appendix  E).  The  submodules  consist  of  the  encoded  knowledge 
of  possible  disaster  scenarios  which  could  occur.  These 
submodules  only  represent  what  the  "expert"  has  anticipated 
as  possible  disasters,  and  the  completeness  of  the  knowledge 
base  depends  greatly  upon  the  knowledge  of  the  expert,  the 
thoroughness  of  the  system  design,  and  the  completeness  of 
the  analysis  and  coding.  In  general,  this  will  not  be 
enough  to  cover  everything  possible  and  that  is  where  the 
second  key  objective  of  DECA  comes  in.  The  second  objective 
of  DECA  is  to  discriminate  between  the  root  cause  and  the 
side  effects.  Since  these  large  systems  have  built  in 
redundancies,  usually  there  will  be  only  one  piece  of 
equipment  failing  at  a  time.  After  DECA  has  ascertained 
what  is  really  important,  it  can  then  point  the  operator  in 
the  right  direction  even  though  it  has  not  found  out  what 
the  exact  cause  of  the  problem  is. 

One  important  facet  of  DECA  is  its  ability  to  direct 
the  user  toward  the  source  of  the  problem  if  it  can  not 
figure  out  the  exact  cause  of  the  problem.  This  feature  is 
important  for  2  reasons:  1)  People  can  not  think  of  all  the 
possibilities  of  what  might  go  wrong  with  a  large  system, 
and  2)  The  system  will  "ignore"  the  side  effect  alarms  and 
give  the  operators  the  guidance  so  they  can  focus  their 
attention  on  the  problem.  Also  this  direction  will  prevent 
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the  operators  from  being  overburdened  with  "too  much 
information".  When  DECA  fails  to  clearly  diagnose  the 
malfunction  in  the  system,  it  will  list  the  parameters, 
their  priorities,  and  where  the  operators  should  concentrate 
their  efforts.  This  is  something  that  was  needed  during  the 
TMI-2  accident,  for  there  were  so  many  side-effect  alarms 
going  off,  that  the  operators  failed  to  notice  the  block 
valve  was  stuck  open  until  after  the  damage  was  done  to  the 
reactor  core. 

In  the  example  of  TMI-2  (appendix  E),  there  are  only 
nine  parameters  monitored,  so  there  are  not  that  many 
scenario  submodules  defined,  but  enough  to  prove  the 
validity  of  the  system.  Table  3.3  shows  a  list  of  scenarios 
and  the  parameters  which  would  be  affected  for  the  TMI-2 
accident.  For  example,  the  scenario  9  and  10  are  affected  by 
the  parameters  SG1-P,  SG1-L,  SG2-P,  SG2-L ,  and  CL1-T. 
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Table  3.3  Scenario  -  Parameter  Relation  Chart 


PARAMETERS  ' 

1  1 
-1 _ _ 

1 

1 

P 

P 

H 

S 

S 

Q 

S 

S 

C 

1 

1 

1 

1 

Z 

Z 

L 

G 

G 

N 

G 

G 

L 

1 

1 

1 

1 

1 

R 

R 

1 

1 

1 

T 

2 

2 

1 

1 

1 

1 

1 

1 

f 

1 

P 

L 

T 

P 

L 

P 

P 

L 

T 

1 

1 

t 

1 

#  Scenario 

1  Pressurizer  Leak 

2  Block  Valve  Leak 

XX  XX  XX 

XX  X  X  X  X  X 

3  Pipe  Rupture  (Drain) 

4  Drain  Tank 

XX  X 

XX  X 

5  Pipe  Rupture  PCS  hot 

6  Pipe  Rupture  PCS  cold 

XX  XXX 

XXX  XX 

7  Reactor  Pump 

8  Steam  Generator  PCS 

XX  XX 

XXX  XXX 

9  Steam  Generator  SCS 

10  Pipe  Rupture  SCS 

XX  XXX 

XX  XXX 

1 1  SCS  Feedwater  Pump 

12  SCS  Turbine  Trip 

XX  XXX 

XX  XXX 

x  x 
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In  a  format  more  conducive  to  list  processing  (Lisp)  we 
arrange  the  parameters  in  the  following  manner: 


Table  3.4  Parameter  -  Scenario  List 


PARAMETER _ POSSIBLE  SCENARIO 


P2R-P 

1 

2 

3 

4 

PZR-L 

1 

2 

3 

4 

HL1-T 

6 

7 

8 

SGI  -P 

1 

2 

5 

6 

7 

8 

9 

10 

1  1 

12 

SG1-L 

1 

2 

5 

6 

8 

9 

10 

1  1 

12 

QNT-P 

2 

3 

4 

SG2-P 

1 

2 

5 

6 

7 

8 

9 

10 

1  1 

12 

SG2-L 

1 

2 

5 

6 

8 

9 

10 

1  1 

12 

CL1-T 

5 

7 

8 

9 

10 

1  1 

12 

These  are  the  submodules  which  will  have  to  be  searched  via 
the  lookahead  capability  (see  appendix  E)  of  DECA  because  of 
the  out  of  bounds  condition  in  the  parameters.  The  object 
is  to  see  how  closely  actual  data  matches  the  expectations 
and  draw  conclusions  from  these  correlations. 


Chapter  4 
Inference  Engine 
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The  previous  chapter  explains  the  knowledge  base 
structure  and  the  mechanism  to  assign  severity.  The  possible 
scenarios  (disasters)  have  also  been  defined.  This  chapter 
deals  with  the  decision  mechanism  and  parameter  usage  in 
DECA. 

4.1  Lookahead  Mechanism  and  Scenario  Evaluation 

Consider,  for  example,  an  instance  of  the  parameter 
P2R-P  is  1180  psig.  Through  the  first  stage  DECA  will  flag 
PZR-P  and  give  it  a  severity  of  LLL  (qualitatively 
translated  as  very  very  low).  Next  PZR-P  is  checked  to  see 
which  submodule  (context  tree)  should  be  searched.  From  the 
table  it  indicates  the  scenarios  1,  2,  3,  and  4  (i.e. 
pressurizer  leak,  pressurizer  block  valve,  pipe  rupture  in 
the  drain  line,  and  the  drain  tank).  This  method  is  similar 
to  the  MYCIN  Lookahead  mechanism  (Findout  and  Monitor;  see 
appendix  B).  What  DECA  does  before  it  reaches  a  conclusion 
(e.g.  that  there  is  a  pressurizer  leak),  is  it  will  look 
ahead  at  these  possible  scenarios  and  determine  if  the 
criterion  is  met  for  each  possible  scenario  to  occur.  The 
scenario  which  most  closely  fits  the  data  will  be  the  one 
chosen  by  DECA  as  the  disaster.  If  there  isn’t  a  close 
enough  match,  then  DECA  will  predict  probable  cause(s)  of 
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malfunction,  the  parameter  priority,  and  suggest  items  or 
subsystems  to  be  considered  more  closely.  In  the  TMI-2 
example,  with  PZR-P  out  of  bounds,  the  lookup  mechanism  will 
indicate  that  scenario  #1  (pressurizer  leak)  is  a 
possibility,  but  the  following  parameters  will  also  have  to 
be  out  of  bounds:  PZR-P,  SG1-P,  SG1-L,  SG2-P,  SG2-L  in  order 
to  have  a  strong  likelihood  of  occuring. 

4.2  Solution  Search 


Next  DECA  executes  the  rules  to  check  the  severity  of 

the  parameters  to  see  how  closely  they  match  with  the 

context  trees  (see  appendix  F).  If  there  is  a  good  match 

between  the  scenarios,  expected  data,  and  parameter 

criticality,  then  a  prompt  would  appear  on  the  screen: 

Scenario  selected  is; 

Scenario  Number  8 

Scenario  Description:  Steam  Generator  - 

Primary  Coolant  System 

Confidence  5/6 

If  there  is  more  than  one  plausible  scenario  considered, 
DECA  would  list  them  in  rank  order  from  highest  to  lowest 
likelihood  similar  to  this  example: 

Scenarios  that  were  considered  as  possible  choices  but  not 
selected  are: 


Scenario  Ratio  Description 


8  5/6 

5  4/5 

1  2/3 

12  3/5 

1 1  3/5 

10  3/5 

2  4/7 


Steam  Generator  -  Primary  Coolant  System 
Pipe  Rupture  -  Hot  Leg,  Primary  Coolant 
Pressurizer  Leak 

Turbine  Trip  -  Secondary  Coolant  System 
Feedwater  Pump  -  Secondary  Coolant  System 
Pipe  Rupture  -  Secondary  Coolant  System 
Block  Valve  Leak 


6 

2/5 

Pipe 

Rupture 

-  Cold  Leg,  Primary  Coolant 

4 

1/3 

Drain 

i  Tank 

3 

1/3 

Pipe 

Rupture 

-  (drain  tank) 

If  the 

system 

could 

not  make 

up  its  mind,  then  it  would  also 

list  the  out  of  bounds  parameters  on  the  screen  in  order  of 
highest  to  lowest  priority. 


No  scenario  selected,  not  confident  enough. 
The  parameter  and  priorities  are  as  follows: 


PZR-L 

10 

QNT-P 

10 

PZR-P 

10 

SG1-L 

9.3 

SG2-L 

9.3 

CL1-T 

8.6 

SGI  -P 

8.5 

Scenarios  that  were  considered  as  possible  choices  but  not 
selected  are: 


Scenario 

Ratio 

Description 

8 

2/3 

Steam  Generator 

-  Primary 

Coolant 

System 

1 1 

3/5 

Feedwater  Pump  - 

Secondary 

■  Coolant 

.  System 

10 

3/5 

Pipe  Rupture 

Secondary 

Coolant 

System 

5 

3/5 

Pipe  Rupture  - 

Hot  Leg, 

Primary 

Coolant 

1 

1/2 

Pressurizer  Leak 

2 

3/7 

Block  Valve  Leak 

12 

2/5 

Turbine  Trip 

Secondary 

Coolant 

System 

6 

2/5 

Pipe  Rupture 

Cold  Leg, 

Primary 

Coolant 

4 

1/3 

Drain  Tank 

3 

1/3 

Pipe  Rupture  - 

(drain  tank) 

This  way,  even  if  the  system  fails  to  generate  a  solution, 
it  will  be  able  to  direct  the  operator  to  the  source  of  the 


trouble. 
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4.3  Context  Trees  and  Scenario  Ranking 

If  we  take  scenario  number  one  (Table  3.3),  the 
pressurizer  leak  from  the  lookahead  database,  it  shows  that 
the  following  parameters  should  not  be  in  normal  operating 
mode:  P2R-P,  PZR-L,  SG1-P,  SG1-L,  SG2-P ,  SG2-L .  The  context 
tree  (discussion  given  in  appendix  E)  contains  rules  to 
check  the  parameters  (i.e.  High  (H)  or  Low  (L))  as  well  as 
the  severity  to  see  how  well  the  present  data  fits  the 
scenario. 

For  the  pressurizer  leak,  encoded  into  the  context 
trees  are  the  rules  to  match  the  data  with  the  anticipated 
data  of  the  scenario.  From  this  matching  operation  the 
mechanism  will  determine  a  qualitative  value  of  the  match. 
DECA  gives  three  levels  of  matching:  High,  Medium,  and  Low. 
These  three  levels  will  give  DECA  a  guide  for  further 
consideration  of  the  scenario  it  is  evaluating.  If  there  is 
a  high  match,  DECA  will  give  it  major  consideration;  a 
medium  match  will  get  a  minor  consideration,  and  for  a  low 
match  the  scenario  will  probably  not  get  considered.  Figure 
4.1  summarizes  the  pattern  matching  process. 


41 


PRESSURIZER  LEAK 


/  :  \ 

/  :  \ 


/ 


rules  and  patterns  to  match  with  data 


High  Match  -  Major  Concern 
Moderate  Match  -  Minor  Concern 
Low  Match  -  Improbable 


Figure  4.1  Qualitative  Match  for  Scenarios 


4.4  Parameter  Prioritization 

At  the  same  time,  the  system  will  look  at  the  problem 
from  a  parameter’s  viewpoint.  This  perspective  is  as 
follows:  the  parameter  (e.g.  PZR-P)  gets  the  following  data 

after  checking  the  database  for  possible  scenarios  (e.g.  1, 
2,  3,  4).  DECA  then  looks  at  the  scenario  ratio  match  data 
to  see  how  well  each  scenario  correlates  with  the  out  of 
bounds  parameters.  The  better  the  match  of  the  other 
parameters  present  with  these  scenarios,  the  more  likely  one 
of  these  scenarios  is  occurring  in  the  process.  An  higher 
likelihood  for  a  given  scenario  will  increase  the  parameter 
importance.  DECA  then  assigns  a  greater  likelihood  of  each 
of  these  scenarios  as  of  being  present.  For  the  parameter 
PZR-P,  the  Lookahead  mechanism  points  to  scenarios  1,  2,  3, 
and  4  (Table  4.1). 
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Table  4.1  Parameter  Priority  Database  for  P2R-P 


P  2  R  -  P 


!  Expectation  Match 

Parameter  Priority 

Rank 

!  1  2 

3 

4 

HIGHEST 

10 

|  2 

3 

4 

8.5 

;  1 

3 

4 

8.5 

1  2 

3 

6 

1  1  2 

4 

6 

1 

3 

4 

;  i 

4 

4 

!  2 

3 

4 

!  2 

4 

4 

3 

2.5 

4 

2.5 

;  2 

LOWEST 

1 

!  i 

1 

a>  ct> 
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This  analysis  will  be  performed  for  each  flagged  parameter 
and  have  a  ranking  of  parameter  priorities.  In  the  case  of 
one  or  more  parameters  having  the  same  ranking,  the  severity 
(e.g.  H,  LL,  etc.)  will  be  used  to  determine  the  relative 
differences  in  importance. 

4.5  Determining  a  Solution 

In  a  similar  fashion  now  that  there  is  a  list  of 
parameter  priorities  (which  will  be  displayed  to  the 
operator  soon),  a  priority  ranking  for  each  possible 
scenario  is  given.  Earlier,  it  was  quantitatively  determined 
how  critical  the  scenario  is  (i.e.  severity).  Now  DECA 
refines  the  ranking  of  the  scenarios  to  find  the  most 
critical  problem.  For  our  example  with  the  parameter  PZR-P, 
the  scenarios  to  look  at  (SI,  S2 ,  S3,  and  S4)  have  already 
been  determined.  Also  parameter  rank  for  all  the  out  of 
setpoint  bounds  parameters  have  been  determined.  Now, 
search  a  context  tree.  Table  4.2  shows  the  different 
combinations  of  the  context  tree  for  PZR-P. 

DECA  then  takes  the  priority  rank  and  the  scenario 
which  matches  the  closest  with  the  system  data,  and  outputs 
what  it  thinks  is  the  most  likely  scenario  and  a  list  of  the 
parameters  in  rank  order.  Also,  the  output  will  have  a 
recommendation  of  how  to  attack  the  situation  at  hand.  This 
output  will  meet  several  objectives,  they  are:  1)  the 
ability  to  take  vast  amount  of  information  of  the  system 
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state  and  keep  only  relevant  data,  2)  Figure  out  the  most 
likely  cause  of  what  is  wrong  with  the  system,  and  3)  Give  a 
priority  of  the  parameters  so  the  technicians  can 
concentrate  the  root  of  the  problem  rather  than  treat  the 
symptoms . 

Another  aspect  of  the  system  which  will  help  in  its 
deployment  in  the  field  is  the  way  the  operators  can  modify 
the  knowledge.  In  the  debug  phase  for  a  new  application, 
DECA  can  also  display  the  a  priori  information  for  ranking 
of  the  parameters,  the  combinations  of  scenarios,  the 
submodule  data,  and  expectations  of  qualitative  knowledge, 
as  well  as  all  On  Line  Databases  so  the  operator  can  be 
consulted  and  initiate  refinement  of  the  data.  This  feature 
can  be  thought  of  as  "Off-Line  Configuration”,  or  "Off-Line 
Learning" . 


Table  4.2  Combining  Parameter  and  Scenario  Priorities 


Context:  Most  Critical  Parameter 

Lookahead:  St,  S2,  S3,  S4 


Parameter:  Criticality 
highest  1 
J  2 

!  3 

J  4 

!  5 

V  6 

lowest  7 


w.r.t.  the  analysis  data 
( PZR-P ) 

( PZR-L ) 

(SG1-P) 

( SG2-P ) 

(SG1-L) 

( SG2-L ) 

(QNT-P ) 


Expectation  of  Scenario  rank 


(St  V  S2 ) 
SI 

A 

A 

(S3  V  S4 )  Critical 

S2 

Major 

Major 

SI 

A 

S3 

Minor 

SI 

A 

S4 

Mi  nor 

S2 

A 

S3 

Minor 

S2 

A 

S4 

Minor 

S3 

S4 

Improbable 
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Chapter  5 

Implementation  of  the  DECA  System 

The  DECA  system  has  been  successfully  implemented  on  a 
Symbolics  3670  Lisp  Machine  using  the  Symbolics  Common  Lisp 
Language  and  its  object  oriented  extension  Flavors.  It  also 
has  been  tested  using  real  data  from  the  TMI-2  accident. 

5.1  Selection  of  Lisp  as  the  Programming  Language 

Lisp  has  been  chosen  as  a  language  for  implementation 
for  several  reasons.  First,  the  comprehensive  set  of  tools 
to  work  with  make  it  ideally  suited  for  rapid  prototyping. 

If  a  change  is  needed,  it  is  quite  easily  implemented. 

Second  is  the  modular  structure  of  the  Lisp  language.  Being 
able  to  set  up  many  functions  enables  the  system  to  be 
broken  up  into  functional  parts,  this  in  turn  also  helps  in 
the  software  maintenance. 

Another  aspect  which  is  very  important  to  the  DECA 
application  is  Lisp’s  ability  to  evaluate  both  numbers  and 
symbols.  The  symbolic  processing  feature  enables  the 
machine  to  run  in  a  manner  similar  to  the  way  humans  think, 
with  symbols.  DECA  is  able  to  use  symbols  as  keywords  in  its 
reasoning.  For  example,  the  setpoint  databases  contain  an 
item  which  is  used  to  indicate  what  the  mode  of  operation  is 
(e.g.  normal).  It  can  use  symbolic  data  as  easily  as  it  can 
use  numeric  data,  thus  the  system  can  be  designed  more 
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closely  to  the  way  humans  think.  The  symbolic  design 
facilitates  the  encoding  of  knowledge  from  the  system 
experts  and  the  debugging  of  the  application  DECA  is  being 
applied  to. 

Compared  to  other  structured  languages,  Lisp  has 
another  significant  advantage,  dynamic  data  structures. 

With  most  languages,  the  programmer  must  set  aside  the 
precise  amount  of  space  for  every  conceivable  data  structure 
which  the  application  may  come  across.  This  can  be 
cumbersome  and  tends  to  make  the  system  inflexible.  Lisp  on 
the  other  hand  does  not  require  this.  Instead,  if  it  needs 
more  space,  it  will  dynamically  allocate  it.  Now  the 
operator  and  programmers  do  not  have  to  think  of  every 
possible  situation,  and  if  the  machine  comes  across  with 
something  new  it  can  just  add  it  to  the  lists.  The  dynamic 
data  structures  is  one  of  the  primary  reasons  why  Lisp  is 
used  for  rapid  prototyping  applications.  After  the  system 
has  been  thoroughly  tested,  it  then  can  be  translated  to  a 
language  such  as  C,  which  interfaces  with  hardware  better, 
if  necessary. 

The  object  oriented  extension,  Flavors  [WeinrSO],  was 
incorporated  into  DECA.  Flavors  help  keep  track  of  the  data 
and  can  be  organized  into  objects.  For  example,  all  the 
setpoint  values  for  a  variable  (e.g.  PZR-P)  were  organized 
into  an  object.  Flavors  arranges  the  data  into  a  well 
organized  structure  which  contain  the  interrelationships 
between  the  pieces  of  data.  This  organization  helps 


48 


facilitate  the  rapid  prototyping,  and  dynamic  databases. 

5.2  Speed  Considerations 

The  purpose  of  the  DECA  system  is  to  be  able  to  monitor 
large  systems  in  real  time.  Unless  it  can  do  all  the 
calculations  in  the  time  between  sensor  data  readings,  the 
system  will  be  of  little  use.  For  the  applications  being 
looked  at  in  the  thesis;  chemical  process  control ,  nuclear 
reactor  control,  space  systems  telemetry,  and  flight  control 
systems;  DECA  will  need  to  have  all  calculations  completed 
in  a  time  period  of  5  -  10  seconds  for  the  chemical  and 
nuclear  processes,  and  10  -  100  msec,  for  the  flight 
controls.  The  differential  in  time  is  due,  in  part,  to  the 
nature  of  the  implementation  purpose.  For  a  chemical 
process,  DECA  will  be  more  of  a  supervisor/advisor  for  the 
system  operators  and  humans  will  not  react  much  faster  than 
the  5-10  seconds.  While  for  the  flight  control  systems, 
DECA  will  be  an  automated  system,  initiating  all  of  its  own 
conclusions. 

To  help  the  system  meet  its  processing  time 
constraints,  it  must  be  deployed  with  fast  hardware,  for 
example  the  Symbolics  computers,  Lisp  on  a  chip 
microprocessors  (e.g.  Symbolics  Ivory,  TI  Explorer  Chip),  or 
32-bit  high  speed  microprocessors  (e.g.  Intel  80386, 

Motorola  68030 ) . 

Another  consideration  for  speed  is  the  implementation 
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language.  For  chemical  or  nuclear  processes  (slow),  Lisp 
will  generally  work.  While  for  a  high  speed  dynamical 
process  (e.g.  flight  controls),  specialized  Lisp  hardware  or 
a  language  such  as  C  may  be  necessary  to  use,  for  they  are 
optimized  for  high  speed  execution. 

Furthermore,  the  amount  and  type  of  sorting  performed 
on  the  data  should  be  carefully  controlled.  There  should  not 
be  any  more  sorting  than  necessary,  and  the  type  of 
algorithm  to  perform  the  sorting  must  be  carefully 
selected.  For  DECA,  sorting  is  done  only  when  a  ranking  is 
needed,  and  it  employs  a  modified  quicksort  routine. 

A  final  consideration  for  execution  speed  is  with  the 
data  structure  used.  To  keep  calculations  to  a  minimum, 
data  should  be  kept  to  a  minimum.  Lisp  and  its  dynamic  data 
lists  also  help  increase  execution  speed  due  to  the  fact 
that  for  each  cycle  it  only  searches  data  structures  as 
large  as  the  data  contained  in  it. 

5.3  Computer  Input/Output 

Computer  input/output  (i/o)  must  also  be  addressed 
judiciously.  In  general,  terminal  and  disk  i/o  can  lead  to 
system  bottlenecks  since  they  typically  reduced  throughput 
compared  to  the  processor. 

When  designing  and  evaluating  the  system,  the  i/o  must 
be  taken  into  consideration  as  part  of  the  system 
computational  requirement.  In  general  it  means  allowing 
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extra  time  to  load  up  the  data  files  containing  the 
knowledge  of  the  dynamic  process  (e.g.  setpoints,  scenarios) 
as  well  as  the  time  to  load  in  new  system  data  (e.g.  new 
setpoints  for  different  operating  state,  sensor  data).  At 
the  other  end  of  the  process  is  the  i/o  to  the  terminal 
screen  and/or  writing  the  data  to  disk.  When  writing  to  the 
screen,  the  system  is  constrained  for  time  in  two  ways; 
first,  the  speed  which  the  terminal  runs  is  usually  the 

slowest  of  any  part  of  the  computer  system.  Second,  any 

information  which  must  be  absorbed  by  the  operator  cannot 
leave  the  screen  until  the  operator  signals  to.  So  if  there 

is  more  than  one  full  screen  of  data,  there  will  be  a 

tremendous  amount  of  idle  cpu  time  while  the  computer  waits 
for  the  operator  to  digest  the  information. 

If  DECA  is  used  with  a  dynamic  process  where  the 
operator  is  advised  by  DECA  such  as  a  nuclear  plant,  then 
the  i/o  becomes  the  major  bottleneck  to  DECA’s  performance. 
On  the  other  hand,  when  DECA  is  employed  in  a  completely 
autonomous  fashion,  such  as  a  space  vehicle  controller,  then 
the  terminal  i/o  is  not  employed,  and  the  disk  i/o 
requirement  will  probably  be  minimal,  but  the  time  between 
sensor  reports  will  be  at  least  1000  times  smaller,  thus  raw 
cpu  speed  is  the  major  factor.  Chapter  6  shows  how  the 
processing  times  differ  with  different  i/o  loads. 
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5.4  Dynamic  Databases 

As  mentioned  earlier,  Lisp  makes  it  very  easy  to 
implement  dynamic  databases.  This  is  because  the  basic  Lisp 
form,  the  list,  can  be  modified  quickly  and  in  many 
different  ways.  It  can  also  contain  both  numeric  and 
symbolic  data,  and  functions  can  easily  manipulate  them. 

The  DECA  system  took  advantage  of  Lisp’s  list 
manipulation  abilities.  For  example,  when  processing  a  run, 
DECA  will  search  many  lists  for  the  appropriate  data  which 
it  may  reference  or  it  may  add  new  data  to  the  list.  One  way 
it  accomplishes  this  is  by  incorporating  the  setf  function 
into  the  code.  The  setf  is  a  function  in  lisp  which  will 
retrieve  the  part  of  a  list  which  matches  the  structure 
given  (first  argument)  with  the  new  structure  encountered 
(second  argument).  Functions  similar  to  the  setf  function 
increase  the  speed  of  data  manipulation  tremendously.  Also, 
they  make  the  coding  easier  than  it  would  be  using  other 
languages,  since  one  does  not  have  to  worry  where  the  data 
is  stored  aside  from  the  name  of  the  list.  In  C,  Pascal,  or 
Ada,  there  will  be  a  large  effort  just  to  control  the  data, 
while  Lisp  will  let  one  use  the  data. 

5.5  Separation  of  the  Knowledge  Base  and  Inference  Engine 

During  the  development  of  the  DECA  system,  great  care 
was  taken  to  make  sure  that  the  knowledge  base  and  the 


52 


inference  engine  were  kept  separate.  There  are  several 
reasons  why  the  two  major  parts  of  the  Expert  System  should 
be  separate. 

First,  it  will  enhance  software  maintainability.  The 
inference  engine  will  exist  in  several  modules.  Thus  if  one 
wants  to  change  some  function  of  DECA,  just  access  the 
module,  make  the  change,  and  recompile.  To  update  the 
knowledge  about  the  process,  then  only  the  data  files  need 
be  updated.  Overall,  the  separate  modular  format  enables, 
the  users  to  easily  access  any  part,  as  well  as  keep 
everything  organized.  If  the  knowledge  and  data  were 
threaded  together  in  the  same  code,  it  would  be  nearly 
impossible  to  maintain  and  update  the  system  for  a  large 
appl i cation . 

Secondly,  it  makes  the  DECA  system  portable.  That  is, 
DECA  has  been  designed  to  be  used  in  all  dynamical 
processes.  For  its  demonstration  of  feasibility  in  this 
thesis,  DECA  was  applied  to  the  Three  Mile  Island  accident. 
If  one  wants  to  apply  it  to  monitor  some  other  process,  new 
data  files  would  have  to  be  written  which  contain  the 
knowledge  of  the  process  to  be  controlled. 

Finally,  the  separation  kept  the  development  of  the 
inference  engine  generic.  More  specifically,  when  coding  the 
inference  engine  there  was  not  any  influences  on  the 
software  design  attributed  to  any  particular  application. 

The  structure  was  designed  for  use  with  any  dynamical 


process . 
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5.6  DECA  Architecture  Planning 

When  implementing  DECA,  great  efforts  were  taken  to 
fully  develop  the  design  of  the  system  architecture  before 
any  code  was  written.  It  was  important  to  make  sure  that  the 
whole  process  was  carefully  planned  out.  Some  standard  steps 
should  be  taken  whenever  any  software  is  being  developed. 
They  are: 

-Carefully  research  the  topic  cf  the  application,  and 
develop  the  problem  thoroughly. 

-Define  the  process  flow.  Developing  a  flowchart  will 
help  visualize  what  is  occurring  in  the  system. 

-Use  the  flowchart  to  develop  the  code.  Breaking  the 
code  into  modules  according  to  function  will  facilitate 
software  debugging  and  maintenance. 

-Employ  a  top  down  approach  to  the  system  design,  and 
bottom  up  approach  for  coding. 

Other  features  which  were  incorporated  into  DECA  were 
software  interfaces  to  outside  models  and  ability  to  use 
data  and  databases  from  multiple  sources. 

The  incorporation  of  interfaces  will  increase  the 
usefulness  of  the  software  for  it  will  enable  DECA  to  use 
other  information  to  arrive  at  its  decisions.  For  example, 
in  the  TMI-2  example,  a  single  setpoint  database  was  used. 
DECA  has  the  ability  to  use  multiple  setpoint  databases 
located  on  several  computers.  In  TMI  2  the  setpoint  was 


labeled  normal,  there  could  have  been  another  setpoint 
database  for  a  shutdown  mode.  This  shutdown  mode  database 
could  have  been  on  another  computer,  and  DECA’s 
setpoi nt-data-1 i st  would  direct  DECA  to  the  other  computer. 
Also,  the  databases  do  not  have  to  be  an  array  of  numbers, 
it  could  be  an  analytical  model  which  calculates  the 
setpoints . 

Another  useful  capability  is  to  hook  into  simulation 
models.  As  an  example,  DECA  could  call  on  a  computer 
simulation  to  validate  its  conclusions  before  it  makes  a 
recommendat i on . 

The  ability  to  access  other  information  makes  DECA  more 
useful.  DECA  adds  more  capability  to  the  system  monitoring 
without  losing  the  benefits  of  the  past  work  done  in  the 
area.  It  could  be  considered  analogous  to  computer  hardware 
being  upward  compatible;  older  software  can  be  used  on  new 
and  improved  hardware. 
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Chapter  6 

Results  and  Conclusions 

In  this  chapter,  the  runtime  results  of  the  DECA  system 
will  be  discussed.  DECA  was  evaluated  using  the  real  time 
data  from  the  Three  Mile  Island  accident.  Appendix  E 
contains  the  data  used  for  the  knowledge  base  data  files. 

6 . 1  Test  Runs 

Before  the  system  was  executed  using  TMI-2  sensor  data, 
DECA  was  debugged  using  fictitious  data  which  would  test  the 
extremes  which  DECA  might  encounter  during  a  real 
application.  The  following  data  was  used  for  the  test  run 
for  fictitious  times  of  5,  10,  and  15  seconds. 

((05  (2150  222  606  940  160  3  940  160  558)) 

(10  (2260  270  606  870  42  1.9  910  42  635)) 

(15  (2380  282  610  870  29  0.9  860  42  635))) 

The  sublist  associated  with  each  system  time  value  contains 
the  readings  of  each  of  the  nine  parameters  in  the  TMI-2 
example.  The  parameters  are  always  read  into  DECA  in  the 
same  order.  The  order  for  TMI-2  was  PZR-P,  PZR-L,  HL1-T, 
SG1-P,  SG1-L,  QNT-P,  SG2-P,  SG2-L ,  and  CL1-T. 

The  above  data  was  used  to  test  DECA’s  ability  to  work 
in  the  middle  of  the  road  and  at  the  two  extremes.  Time  05 
was  used  to  test  DECA  when  none  of  the  parameters  were  out 
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of  bounds.  Looking  at  the  data  output  file,  appendix  D,  it 
is  apparent  that  DECA  just  skimmed  through  its  routines 
without  doing  anything  since  everything  was  alright. 

Time  step  10  represents  what  could  be  thought  of  as  a 
typical  load  to  DECA,  that  is  several  parameters  it  is 
monitoring  are  out  of  bounds.  The  output  file  in  appendix  D 
shows  the  intermediate  values  as  DECA  is  running.  For  a 
conclusion,  DECA  was  not  confident  enough  with  the  data  to 
decide  on  a  scenario,  so  it  just  listed  out  the  parameters, 
their  ranks,  the  scenarios  and  their  ratios  which  it  had 
considered.  DECA’s  conclusions  are  shown  below. 


DECA’s  conclusions  for  system  time:  10 
No  scenario  selected,  not  confident  enough. 


The  parameter  and  priorities  are  as  follows: 


PZR-L 

10 

QNT-P 

10 

PZR-P 

10 

SGI  -L 

9.3 

SG2-L 

9.3 

CL1-T 

8.6 

SGI  -P 

8.5 

Scenarios  that  were  considered  as  possible  choices  but  not 
selected  are: 


Scenario  Ratio  Description 


8 
1 1 
10 

5 
1 
2 

12 

6 
4 
3 


2/3  Steam  Generator  -  Primary  Coolant  System 
3/5  Feedwater  Pump  -  Secondary  Coolant  System 
3/5  Pipe  Rupture  -  Secondary  Coolant  System 

3/5  Pipe  Rupture  -  Hot  Leg,  Primary  Coolant 

1/2  Pressurizer  Leak 

3/7  Block  Valve  Leak 

2/5  Turbine  Trip  -  Secondary  Coolant  System 

2/5  Pipe  Rupture  -  Cold  Leg,  Primary  Coolant 

1/3  Drain  Tank 

1/3  Pipe  Rupture  -  (drain  tank) 


End  of  data  evaluation  for  system  time:  10 
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Time  step  15  is  an  example  of  the  sensor  data 
correlating  well  with  DECA’s  knowledge.  Thus  it  is  confident 
enough  to  select  a  scenario  as  likely  occurring  in  the 
system  at  that  time.  For  this  data,  it  has  decided  that  the 
problem  is  occurring  in  the  steam  generator  on  the  primary 
coolant  side.  The  conclusion  is  shown  below  (extracted  from 
the  runtime  output  file  appendix  D). 


DECA’s  conclusions  for  system  time:  15 

Scenario  selected  is; 

Scenario  Number  8 

Scenario  Description  (Steam  Generator  -  Primary  Coolant 
System  ) 

Confidence  5/6 

The  parameter  and  priorities  are  as  follows: 


PZR-L 

10 

QNT-P 

10 

PZR-P 

10 

SGI  -L 

9.3 

SG2-L 

9.3 

CL1-T 

8.6 

SGI  -P 

8.5 

SG2-P 

8.5 

Scenarios  that  were  considered  as  possible  choices  but  not 
selected  are: 

Scenario  Ratio  Description 


8 

5/6 

Steam  Generator 

-  Primary  Coolant  i 

System 

5 

4/5 

Pipe  Rupture  - 

Hot  Leg,  Primary  Coolant 

1 

2/3 

Pressurizer  Leak 

12 

3/5 

Turbine  Trip 

-  Secondary  Coolant 

System 

1  1 

3/5 

Feedwater  Pump 

-  Secondary  Coolant 

System 

10 

3/5 

Pipe  Rupture 

-  Secondary  Coolant 

System 

2 

4/7 

Block  Valve  Leak 

6 

2/5 

Pipe  Rupture  - 

Cold  Leg,  Primary  Coolant 

4 

1/3 

Drain  Tank 

3 

1/3 

Pipe  Rupture  - 

(drain  tank) 

End  of  data  evaluation  for  system  time:  15 


58 


The  output  is  useful  in  several  ways.  First,  it 
organizes  the  data  for  the  operators.  It  also,  displays  it 
in  rank  order.  Displaying  in  rank  order  will  avoid  giving 
the  operator  information  overload  for  they  can  just  look  at 
the  top  of  the  list  and  see  what  is  most  important.  Finally, 
DECA  also  lists  the  scenarios  which  it  considered.  Looking 
at  the  scenarios  considered  and  seeing  the  ranks  of  the 
parameters,  the  operators  can  use  their  system  knowledge  to 
assess  the  problem.  In  time  step  15,  they  would  probably 
concentrate  on  the  Primary  Coolant  System  piping,  since  it 
was  considered  most  often  by  DECA. 

From  DECA’s  output,  it  can  be  seen  that  the  system  has 
met  several  of  its  design  goals,  they  are: 

-It  identifies  and  ranks  the  sensor  data  parameters  in 
order  of  importance. 

-DECA  searches  for  the  scenario  which  is  most  likely 
occurring  and  selects  one,  only  if  it  is  confident 
enough  in  its  data  correlation. 

-It  lists  all  the  relevant  scenarios  which  it 
considered . 

-DECA  gives  a  summary  which  the  operators  can  easily 
understand  the  information  in  it  and  know  where  they 
must  concentrate  their  efforts. 
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6.2  Runtime  Log 

Since  there  is  no  relatively  easy  way  to  check  the 
system  operation  during  execution  (e.g.  MYCIN  has  an 
interface  which  the  user  can  ask  questions),  a  runtime  log 
was  created.  The  runtime  log  consists  of  intermediate 
variables  written  to  disk  during  DECA’s  execution.  After 
DECA  runs  through  a  module  of  code,  it  writes  out  the  values 
to  disk.  As  an  example,  below  is  the  listing  of  the  log  for 
the  variables  from  the  test  run  data  for  time  step  10. 


Intermediate  parameters  for  system  time:  10 

Sensor-record  (2260  270  606  870  42  1.9  910  42  635) 

Oob-parameters  (PZR-P  PZR-L  SG1-P  SGI -L  QNT-P  SG2-L  CL1-T) 

Oob-parameters-values  (2260  270  870  42  1.9  42  635) 

Oob-severity  (H  HH  L  L  LL  L  HHH ) 

Lookahead-scenarios  (123456  789  10  11  12) 

Scenario-data-match-1 ist 

((1  ( SG2-L  SG1-L  SG1-P ) )  (2  ( SG2-L  SG1-L  SGI -P ) ) 

(3  (QNT-P))  (4  (PZR-L))  (5  ( SG2-L  SGI -L  SGI -P) ) 

(6  ( SG2-L  SGI -L ) )  (7  (CL1-T) ) 

(8  (CL1-T  SG2-L  SGI -L  SGI -P ) )  (9  (CL1-T ) ) 

(10  (CL1-T  SG2-L  SGI -L ) )  (11  (CL1-T  SG2-L  SG1-L ) ) 

(12  (CL1-T  SG1-P) ) ) 

Parameters-per-scenar i o-expect 

((1  6)  (2  7)  ('  3)  (4  3)  (5  5)  (6  5)  (7  4)  (8  6)  (9  5) 

(  10  5)  (  1  1  5)  (  12  5) ) 

Scenario-ratio-match-1 ist 

((1  1/2  MINOR)  (2  3/7  MINOR)  (3  1/3  MINOR)  (4  1/3  MINOR) 

(5  3/5  MINOR)  (6  2/5  MINOR)  (7  1/4  IMPROBABLE) 

(8  2/3  MINOR)  (9  1/5  IMPROBABLE)  (10  3/5  MINOR) 

(11  3/5  MINOR)  (12  2/5  MINOR)) 

Scenario-major  NIL 

Scenario-minor  ((8  2/3)  (11  3/5)  (10  3/5)  (5  3/5)  (1  1/2) 

(2  3/7)  (12  2/5)  (6  2/5)  (4  1/3)  (3  1/3)) 

Scenario-improbable  ((7  1/4)  (9  1/5)) 
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Parameter-ratio-match 
( ( P2R-P  ((4)  NIL  (4321)  NIL)) 

( P2R-L  ((4)  NIL  (4321)  NIL)) 

(HL1-T  NIL) 

(SG1-P  ((10)  NIL  (12  11  10  8  6  5  2  1)  NIL)) 

(SG1-L  ((9)  NIL  (12  11  10  8  6  5  2  1)  NIL)) 

( QNT-P  ((3)  NIL  (4  3  2)  NIL)) 

( SG2-P  NIL) 

( SG2-L  ((9)  NIL  (12  11  10  8  6  5  2  1)  NIL)) 

(CL1-T  ((7)  NIL  (12  11  10  8  5)  NIL))) 

Parameter-rank- 1 ist 

((QNT-P  10)  ( PZR-L  10)  ( PZR-P  10)  ( SG2-L  9.3)  (SG1-L  9.3) 
(CL1-T  8.6)  (SG1-P  8.5)  ) 

Parameter-rank- 1 i st 

((PZR-P  PZR-L  QNT-P  10)  ( SGI -L  SG2-L  9.3) 

(CL1-T  8.6)  (SG1-P  8.5)) 

Parameter-rank- 1 ist 

((PZR-L  1C)  (QNT-P  10)  (PZR-P  10)  ( SGI -L  9.3)  ( SG2-L  9.3) 
(CL1-T  8.6)  (SG1-P  8.5)  ) 

Poss i bl e-scenar i os-f or-s i tuat i on 

((8  2/3)  (11  3/5)  (10  3/5)  (5  3/5)  (1  1/2)  (2  3/7)  (12  2/5) 
(6  2/5)  (4  1/3)  (3  1/3)) 

End  of  variable  log. 


The  parameters’  values  are  created  while  DECA  is 
executing  a  particular  function.  Table  6.1  contains  lists  of 
the  function  names  and  the  variables  which  were  modified 
upon  execution  of  the  function.  See  appendix  F  for  the 
complete  listing  of  all  of  DECA’s  functions. 


Table  6.1  Function  Variable  References 


Function  Name  Variables  Modified 

(in  capitals) 


COMPARE-SENSOR-DATA 

oob-parameters 
oob-parameters-val ues 
oob- severity 

GET-SCENARIOS 

lookahead  scenarios 
MATCH-SCENARIO-TENDENCY 

scenar i o-data-match- 1 i st 
M AK E- L I ST-OF-NUM- PAR AMS- EXPECT 

parameters-per-scenar io-expect 

SCENAR IO-QUAL-MATCH 

scenar io-rati o-match- 1 ist 


SPLIT- INTO-MAJ-MINOR 


scenario-major 
scenario-minor 
scenar i o- i mprobabl e 
MAKE-PARAMETER-COMPARISON 

parameter-ratio-match 
parameter-rank- 1 ist 
REFINE-PARAMETER-RANK-TOP 

parameter-rank- 1 ist 


ORDER-MULTIPLES 

parametei — rank- list 
PUT- SCENAR IOS-TOGETHER 

possi ble-scenario-f or-si tuation 
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6.3  Experimentation  of  DECA  with  TMI-2  Data 

After  the  evaluation  of  the  test  runs,  it  was 
determined  that  DECA  appeared  to  be  working  according  to 
desi gn . 

To  show  DECA’s  efficacy,  the  system  was  run  with  data 
from  the  TMI-2  accident.  See  appendix  E  for  the  sensor 
readings  data.  The  run  consisted  of  nine  time  steps  at  0, 

15,  30,  45,  60,  75,  90,  105,  and  120  seconds  after  the 
turbine  trip  occurred  in  the  reactor. 

DECA  completed  the  run  without  a  problem.  The  log  and 
conclusions  for  each  time  step  are  given  in  appendix  D.  From 
those  results,  it  can  be  seen  that  DECA  consistently 
directed  the  operators  to  scrutinize  the  subsystem  where  the 
pressurizer,  block  valve,  and  drain  tank  are  located  in  the 
reactor.  This  is  precisely  where  the  problem  was.  The  stuck 
block  valve  in  the  pressurizer  was  allowing  the  reactor 
coolant  to  drain  out  of  the  system.  For  this  run,  DECA  was 
only  monitoring  nine  parameters,  thus  it  did  not  have  the 
fine  resolution  to  extract  the  intricate  nuances  present  in 
the  system.  Since  the  block  valve,  drain  tank,  and 
pressurizer  directly  affect  each  other,  having  DECA  select 
these  three  problems  continuously  confirms  its  ability  to 
determine  the  area  of  most  importance. 

Also,  it  should  be  noted  that  the  knowledge  base  data 
for  the  scenarios,  their  tendencies,  the  parameter 
tendencies  and  lookahead  scenarios  (that  is  all  except  the 
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setpoints  and  sensor  data)  were  derived  at  with  only  the 
author’s  engineering  experience  and  did  not  utilize  anyone’s 
nuclear  reactor  expertise.  Thus  having  such  promising 
results  from  DECA,  continuously  directing  the  operators’ 
attention  to  the  part  of  the  reactor  where  the  block  valve 
is  located,  demonstrates  the  efficacy  to  the  methodology  of 
qualitative  reasoning  for  monitoring  dynamic  processes. 
Referring  to  the  runtime  output  file  (appendix  D),  we  see 
consistently  the  pressurizer  pressure  and  level  (PZR-P, 
PZR-L)  are  among  the  most  important  parameters  (i.e.  highest 
priority).  These  two  sensors  are  located  adjacent  to  the 
block  valve. 

6.4  Computational  Requirements 

Having  the  qualitative  reasoning  approach  working  meets 
one  of  the  criteria  of  DECA,  but  the  system  is  not  very 
useful  unless  it  can  meet  the  real  time  processing 
requi rements. 

At  present,  DECA  is  in  a  prototype  stage.  That  is,  its 
primary  purpose  is  be  able  to  monitor  a  system  and  advise 
its  operators,  and  to  perform  its  task  in  a  time  limit 
approaching  the  real  time  constraints.  In  actuality,  the 
DECA  system  is  able  to  perform  its  task  with  impressive  real 
time  capabilities.  The  execution  times  vary  according  to 
input/output  (i/o)  load  and  are  explained  below. 

To  get  accurate  results  for  the  execution  times  of  the 
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DECA  system,  Lisp’s  "time"  function  was  used.  The  time 
function  accurately  keeps  track  of  elapsed  time,  time  spent 
waiting  for  i/o  as  well  as  the  amount  and  type  of  lists 
manipulated  internally.  DECA  was  tested  under  a  variety  of 
i/o  loads  with  the  same  set  of  data  in  order  to  determine 
where  the  bottlenecks  occur  during  program  execution.  Note, 
all  times  are  in  physical  seconds. 

The  first  test  was  a  single  run.  The  knowledge  base 
data  files  were  all  loaded,  and  then  DECA  evaluated  the 
sensor  data  for  a  single  time  step.  DECA  then  displayed  its 
results  on  the  computer  terminal.  The  time  required  for  this 
was  14.6732  seconds. 

The  second  test  consisted  of  reading  in  the  knowledge 
base  data  files,  evaluate  a  single  time  step,  and  not  output 
any  information  to  the  terminal.  For  this  run,  6.1779 
seconds  were  required. 

From  the  first  two  runs,  it  is  determined  that  DECA 
takes  about  8.5  seconds  for  terminal  i/o  for  a  small  sized 
application.  The  runs  were  repeated  several  times,  each  run 
yielding  consistent  results  due  to  the  fact  that  the 
Symbolics  is  a  single  user  system  and  one  does  not  have  to 
wait  for  other  jobs  unlike  a  timesharing  system. 

The  third  test  run  consisted  of  a  single  time  step 
evaluation  without  any  i/o  to  disk  or  terminal.  This  test  is 
evaluating  raw  computing  power  of  the  system.  From  the  run, 
the  time  to  process  the  data  was  0.120383  seconds,  or  8.3 
time  steps  could  be  evaluated  per  second.  After  the  third 
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test  run,  it  was  determined  that  the  computer  requires  about 
5.9  seconds  to  load  the  TMI-2  data  files  from  disk. 

It  is  obvious  that  for  a  more  complex  process  these 
times  will  increase,  but  the  time  of  0.12  seconds  to  process 
the  data  which  DECA  is  monitoring  is  well  within  the  design 
goals  of  5-10  seconds  for  the  prototype.  Also,  the  time 
spent  reading  in  the  knowledge  base  may  be  eliminated  if  it 
is  loaded  into  active  memory  prior  to  DECA’s  operation.  That 
would  alleviate  a  large  portion  of  the  overhead  and  make 
DECA  practical  for  some  processes  requiring  a  little  faster 
turnaround  (eg.  0.5  to  1.0  seconds). 

In  the  final  test  run,  DECA  was  tested  with  all  nine 
time  steps.  It  consisted  of  loading  in  the  knowledge  base, 
sensor  data,  evaluating  each  time  step,  and  writing  to  disk 
the  variable  log  and  DECA’s  conclusions.  For  this,  DECA 
required  13.8393  seconds.  The  time  interval  between  sensor 
readings  was  15  seconds  or  135  seconds  for  all  nine 
readings.  Since  DECA  did  the  calculations  in  13.8  seconds, 
the  system  is  more  than  adequate  in  terms  of  meeting 
computational  requirements.  This  extra  time  will  be  eaten  up 
when  DECA  is  run  with  applications  consisting  of  many  more 
parameters  and  scenarios. 
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6.5  Conclusions 

In  most  of  the  physical  systems,  reasoning  is  based  on 
qualitative  premises.  For  example,  when  a  mechanic  fixes  a 
car,  he  will  not  hook  up  a  vast  array  of  sensors,  devise 
mathematical  models  of  the  car  and  employ  optimization 
techniques  to  simulate  and  determine  what  is  wrong  with  it. 
The  garage  has  neither  the  time  nor  the  money  to  do  it. 
Instead,  the  mechanic  will  use  his  experience  and 
qualitative  reasoning  to  determine  and  fix  the  problems 
afflicting  the  automobile. 

In  large  dynamic  systems,  financial  resources  may  be 
adequate,  but  time  will  be  a  constraint  to  monitor  and 
evaluate  the  system  in  real  time,  using  complex  analytical 
models  and  global  optimization  techniques.  DECA  typically 
can  be  applied  to  such  scenarios.  It  employs  qualitative 
reasoning  to  narrow  down  possibilities  for  real  time 
monitoring  and  diagnosis  of  dynamical  processes. 

An  implementation  of  the  DECA  system  was  successfully 
developed  in  Lisp  on  a  Symbolics  artificial  intelligence 
computer.  Using  the  Three  Mile  Island  Unit  2  Accident  as  a 
real  world  application,  it  was  shown  that  DECA  is  able  to 
monitor  some  dynamic  processes  in  real  time. 

Another  accomplishment  derived  from  this  research  is 
the  development  of  a  comprehensive  software  architecture  for 
diagnosis  and  evaluation  of  any  dynamical  process.  This 
architecture  was  based  on  past  work  of  Milne  [Milne87]  and 
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offers  flexibility  in  the  use  of  knowledge  in  a  diagnostic 
expert  system. 

One  more  important  point  of  interest  is  in  the 
development  of  the  knowledge  base.  In  dynamical  systems, 
most  often  the  data  is  dynamic  hence  to  incorporate  it  as  a 
part  of  the  expert  system’s  knowledge  base  may  not  be  useful 
from  a  computational  point  of  view.  DECA  uses  a  relational 
schema  for  the  data  which  is  interfaced  with  the  expert 
modules.  This  architecture  is  seen  to  be  beneficial  from  the 
standpoint  of  execution  time. 

To  summarize,  the  experiences  with  DECA  has  led  to  the 
following  conclusions: 

1-  For  real  time  monitoring,  diagnosis,  and  control  of 
dynamic  processes,  qualitative  reasoning  will  be  of 
immense  use. 

2-  Incorporation  of  qualitative  reasoning  as  opposed  to 
the  pure  optimization  approaches  will  help  in 
identifying  the  possible  critical  parameters  along  with 
their  relative  importance  which  will  help  reduce  the 
processing  time  required. 

3-  It  is  necessary  to  handle  data  distinct  from  the 
knowledge  base.  It  is  apparent  that  a  relational  schema 
interface  with  the  reasoning  system  will  be  of  value 
due  to  the  fact  that  the  data  is  dynamic. 

4-  This  experimentation  has  confirmed  the  fact  that 
Milne’s  [Milne87]  architecture  integrated  with  the 
structuring  of  a  dynamic  database  will  be  of  importance 
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in  dynamical  systems. 

5-  DECA  demonstrates  the  point  that  all  dynamical 
systems  share  the  commonalty  of  prioritization  and  the 
generic  scheme  developed  in  this  research  is  useful  in 
almost  every  dynamical  process  control  scenario. 


Chapter  7 
Future  Research 
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Though  the  DECA  system  is  a  prototype,  the  initial 
results  are  encouraging  and  provide  a  strong  argument  toward 
further  expansion  of  the  system’s  capabilities. 

7.1  Solution  Generation 

So  far,  the  main  efforts  of  DECA  were  to  prove  the 
concepts  of  qualitative  information  prioritization.  Not  much 
of  the  effort  in  this  work  was  devoted  to  the  development  of 
customized  solutions  for  every  detail  of  a  process’s 
operation.  Most  efforts  went  into  creating  the  ability  to 
properly  analyze  the  data  and  determine  the  critical  areas 
of  the  process  application  in  a  real-time  manner.  Unless  the 
system  performs  in  real-time,  there  is  little  need  for  a 
comprehensive  solution  generation  capability.  Also,  the 
solution  generation  is  more  specific  to  the  application 
which  DECA  is  being  applied  to,  while  the  thrust  of  this 
thesis  is  to  prove  the  viability  of  DECA  to  all  dynamic 
processes . 

Additional  effort  will  be  to  devise  a  methodology  in 
which  the  recommended  solution  for  each  scenario  can  be 
tailored  according  to  the  parameter  rankings  of  the  sensor 
data.  Special  considerations,  similar  to  the  ones  for 
parameter  expectancy  data,  would  be  needed  to  avoid  a 
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combinatorial ly  explosive  number  of  solutions  (i.e.  one  for 
every  single  parameter  combination). 

7.2  Fuzzy  Logic 

Fuzzy  mathematics  [2adeh65]  have  a  great  potential  in 
the  application  of  quantifying  qualitative  data.  Applying 
fuzzy  math  to  the  evaluations  of  parameter  and  scenario 
ranks  would  help  increase  the  resolution  of  the  results. 

For  example,  at  the  present,  DECA  breaks  up  the  likelihood 
of  the  scenarios  into  three  categories  (major,  minor,  and 
improbable).  With  fuzzy  mathematics  more  subtle  points  can 
be  brought  into  consideration  increasing  the  thoroughness  of 
DECA’s  .evaluation. 

7.3  Source  Code  Translation 

DECA  is  presently  written  in  Lisp.  It  is  an  ideal 
language  for  rapid  prototyping  of  systems  and  handling 
abstract  concepts,  but  it  is  also  known  for  its 
computational  overhead  though  Lisp  Machines  such  as  the 
Symbolics  help  reduce  this  overhead.  Since  a  primary  concern 
of  DECA  is  for  real-time  processing,  and  the  system  will 
eventually  be  interfaced  with  physical  controllers  and 
sensors,  another  language  has  been  targeted  for  the  second 
stage  of  DECA’s  development.  The  language  chosen  is  C.  A 
couple  of  desired  traits  of  C  are  its  very  fast  and 
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efficient  execution,  and  there  are  many  controllers  set  up 
to  be  easily  interfaced  with  it. 

The  main  problem  to  be  addressed  in  this  conversion  is 
C  does  not  have  dynamic  database  capabilities  like  Lisp.  If 
not  done  carefully,  unwieldy  data  structures  could  add  an 
unacceptable  burden  on  the  processor. 

7.4  Integrating  Analytical  Modules 

Though  large  analytical  models  may  require  too  much  cpu 
time,  a  simplified  model  or  simulation  of  a  subsystem  can 
yield  valuable  insight  into  the  current  state  of  a  process 
or  subsystem.  Also,  a  great  deal  of  effort  has  been  spent  on 
the  development  of  analytical  methods.  Future  work  on  DECA 
can  concentrate  on  implementing  several  analytical  models 
which  could  run  in  parallel  with  DECA’s  qualitative  model. 
The  analytical  models  could  be  used  as  a  verification  to 
DECA’s  proposed  conclusions. 

Another  aspect  where  the  use  of  analytical  models  would 
be  beneficial  is  to  simulate  the  proposed  solution  before 
implementing  it  on  the  real  system.  This  way  DECA  could 
avoid  a  potentially  catastrophic  mistake  for  it  would  be 
caught  in  the  simulation. 

Overall,  the  application  of  analytical  elements  in  the 
DECA  system  would  complement  its  qualitative  abilities  and 
increase  the  system’s  reliability. 
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7.5  Distributed  Processing 

DECA  is  being  developed  to  monitor  large  scale  systems 
with  hundreds  or  thousands  of  parameters.  Ir,  order  for  it  to 
be  successful  in  this  area,  the  application  process  should 
be  divided  up  into  its  subsystem  with  a  separate  DECA  system 
monitoring  each  subsystem.  To  integrate  all  the  distributed 
processors  together  into  one  working  entity,  there  will  be 
another  DECA  system  overseeing  all  the  DECA  subsystems  in  a 
me ta  level  fashion.  It  will  monitor,  evaluate,  and  rank  all 
the  conclusions  of  every  subsystem.  The  meta  level  will  work 
with  the  whole  system  and  allow  each  subsystem  to  run 
independently,  but  have  an  override  capability  to  resolve 
conflicts  between  subsystems. 

The  distributed  processing  scheme  is  a  methodology  to 
incorporate  extra  cpu  power  via  multiple  processors,  yet 
still  maintaining  control  ever  the  entire  dynamic  process 
being  monitored. 

7.6  Operator  Interface 

DECA  is  acting  as  an  advisor  to  the  operators  of  the 
dynamic  process  being  monitored.  Thus  it  is  very  important 
to  be  sure  that  the  transfer  of  information  between  DECA  and 
the  operators  is  being  correctly  interpreted.  During  future 
development  phases,  investigations  will  be  made  to  see  what 
is  the  best  way  to  present  the  information,  especially  in 


large  scale  applications. 

Another  area  to  be  developed  is  a  user  friendly 
interface  to  be  used  by  the  process  experts,  who  may  not 
computer  experts,  to  facilitate  DECA’s  acquisition  of 
knowledge  from  them.  A  properly  developed  intorface  will 
greatly  enhance  DECA’s  utility. 
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Appendix  A 

The  System  Query  Language  (SQL) 

Database  Manipulation  Language 

In  recent  years  the  emergence  of  powerful  database 
management  systems  ( DMS ) .  enabling  efficient  manipulation  of 
large  databases  with  relative  ease,  has  lent  itself  to 
widespread  use  as  a  primary  method  of  information  storage. 
One  such  database  design  is  the  relational  database.  The 
basic  structure  of  the  relational  model  consists  of  data 
tables.  These  data  tables  are  called  relations,  and  they 
represent  the  data  itself  and  the  output  of  processing  of 
data  too.  In  a  loose  analogy,  it  could  be  thought  of  being 
similar  to  Frames  and  Slots,  a  common  knowledge 
representation  in  the  Artificial  Intelligence  field.  The 
only  difference,  and  a  rather  large  one  at  that,  is  the 
relational  databases  do  not  support  message  passing  or 
property  inheritance  between  relations,  thus  limiting  its 
domain  of  application. 

The  relations  are  flat  files;  a  two  dimensional  table 
containing  several  properties  of  the  data.  The  basic 
structure  which  makes  up  the  tables  of  a  relational  data 
base  is  the  tuple.  Each  row  of  a  relation  is  called  a 
tuple.  Each  element  of  the  tuple  falls  in  to  a  different 
column.  Each  column  of  the  table  is  an  attribute  of  the 
system.  This  is  somewhat  similar  to  the  top  level  structure 
of  frames.  In  a  relational  model  the  term  key  refers  to  an 
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attribute  which  can  be  used  to  uniquely  identify  a 
particular  tuple.  The  use  of  keys  to  extract  information 
out  of  the  database  makes  it  somewhat  recursive  in  nature, 
which  is  generally  an  ideal  way  to  approach  knowledge 
retrieval  in  Expert  Systems. 

The  retrieval  of  data  is  done  through  the  use  of  a  Data 
Manipulation  Language  ( DML ) .  There  are  four  categories  of 
these  languages  for  relational  data  bases.  They  are 
relational  algebra,  relational  calculus,  transf orm-or i ented 
languages,  and  graphic  systems.  System  Query  Language  (SQL) 
is  a  common  DML,  uses  a  transform-oriented  language.  It 
provides  a  nonprocedural  capability  and  uses  relations  to 
manipulate  given  the  data  into  wanted  results.  The  language 
has  an  English  like  syntax  making  it  easy  to  use.  SQL  is 
also  available  on  most  large  computers,  thus  making  it  a 
good  candidate  for  having  DECA  interface  to  outside 
databases  with  it  and  tap  the  large  amounts  of  data  which 
are  on  these  mainframes. 

Some  of  the  basic  keywords  of  SQL  are:  SELECT,  FROM, 
WHERE,  IN,  COUNT,  SUM,  AVG,  MAX,  MIN,  GROUP  BY,  NOT,  <,  >, 
HAVING,  EXISTS.  SQL’s  syntax  is  straight  forward  lending  to 
a  powerful  interface  to  retrieve  data. 

As  an  example,  consider  the  setpoint  database  (SDB)  in 
table  A . 1 ,  along  with  some  typical  queries: 
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Table  A . 1  Setpoint  Data  Relation  Table 


Setpoi nt [ VAR ,  LLL,  LL,  L,  N,  H,  HH ,  HHH ] 


VARIABLE 

LLL 

LL 

L 

N 

H 

HH 

HHH 

UNITS 

PZR-P 

1200 

1900 

2055 

2150 

2250 

2355 

2400 

psig 

PZR-L 

45 

1  50 

200 

222 

240 

260 

280 

i nches 

HL1-T 

300 

400 

500 

606 

610 

619 

630 

deg  F 

SGI  -P 

800 

850 

900 

940 

1050 

1070 

1105 

psig 

SG1-L 

10 

30 

45 

160 

170 

180 

190 

i nches 

QNT-P 

1 

2 

2.5 

3 

35 

80 

122 

psig 

SG2-P 

800 

850 

900 

940 

1050 

1070 

1105 

psig 

SG2-L 

10 

30 

45 

160 

1  70 

180 

190 

i nches 

CL  1  -T 

300 

400 

500 

558 

610 

619 

630 

deg  F 

Query  1 : 

Get 

the  high 

(H) 

values 

desired  for 

al  1 

relations 

from  the  database.  The  retrieval  schema  is  as  follows: 

SELECT  H 

FROM  SETPOINT 

the  results  returned  would  be  the  data  in  column  H. 


2250 
24C 
610 
1050 
170 
35 
1050 
1  70 
610 

Query  2:  Get  the  name  of  the  parameter  which  has  a  high 
setpoint  value  that  is  greater  than  2000  psig.  The 
retrieval  schema  is  as  follows: 


SELECT 

FROM 

WHERE 

AND 


VARIABLE 
SETPOINT 
UNITS= ’ PSIG ’ 
H  >  2000 


This  would  return  the  variable  P2R-P. 
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One  can  see  SQL  has  a  very  powerful  interface,  and  is 
fairly  straight  forward  to  interface  with  any  other  program. 
Only  the  code  would  have  to  be  written  to  enable  DECA  to 
send  its  own  SQL  commands  to  the  database  computer.  This 
would  help  reduce  the  development  time  of  DECA  since  the 
data  management  facility  for  various  databases  would  not 
have  to  be  written  from  scratch. 
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Appendix  B 

MYCIN’s  Control  Mechanisms 


MYCIN  was  one  of  the  first  successful  Expert  System 
implementations.  Its  purpose  is  to  diagnose  infectious 
bacterial  diseases  and  to  decide  a  treatment  for  the 
patient.  It  is  an  interactive  consultant  used  by  the 
physician  as  a  diagnostic  assistant.  MYCIN  relies  on 
information  from  test  results,  patient  consultation,  and 
internal  system  inferences  to  arrive  at  its  diagnosis.  This 
appendix  describes  some  of  MYCIN’s  internals  as  presented  in 
[ Bucha84] . 

MYCIN’s  task  involves  a  foui — step  decision  problem: 

1-  Decide  which  organisms,  if  any,  are  causing 

significant  disease. 

2-  Determine  the  likely  identity  of  the  significant 

organisms. 

3-  Decide  which  drugs  are  potentially  useful. 

4-  Select  the  best  drug  or  drugs. 

MYCIN  is  a  rule  based  Expert  system.  Typically  the 
rules  are  of  the  form: 

IF  antecedent  is  true> 

THEN  <take  the  designated  action> 
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An  example  rule  is  as  follows  [Bucha84]: 

RULE040 

IF:  1)  The  site  of  the  culture  is  blood,  and 

2)  The  identity  of  the  organism  may  be 
pseudomonas,  and 

3)  The  patient  has  ecthyma  gangrenosum  skin 

THEN: 

There  is  a  strong  suggestive  evidence  (.8) 
that  the  identity  of  the  organism  is 
pseudomonas . 

RULE040  contains  the  Lookahead  property  in  its 
structure.  That  is,  before  RULE040  can  be  executed  as  true, 
the  system  will  have  to  verify  whether  or  not  premise  1,  2, 
and  3  are  true  by  executing  other  rules  in  the  system.  This 
forward  looking  before  making  a  decision  is  the  Lookahead 
mechanism. 

In  MYCIN,  there  are  some  rules  which  have  some  of  the 
same  parameters  in  both  the  premise  and  consequent  (action) 
statements.  Such  rules  are  known  as  sel f-referenci ng .  When 
an  Expert  System  contains  rules  which  are  self-referencing, 
there  must  also  be  a  control  structure  to  prevent  the  system 
from  entering  an  infinite  loop. 

MYCIN  uses  a  goal-oriented  approach  for  executing 
rules.  Two  procedures,  FINDOUT  and  MONITOR,  are  used  to 
control  the  rule  execution  as  well  as  prevent  the  system 
from  entering  an  infinite  loop.  MONITOR  analyzes  the  premise 
of  a  rule,  one  condition  at  a  time,  to  see  if  it  should 
execute  the  consequent.  A  block  diagram  of  MONITOR  is  shown 
in  figure  B.2.  In  FINDOUT  (fig  B.1),  its  purpose  is  to 
obtain  the  missing  information  for  MONITOR  via  other  rules 
or  asking  the  user  for  data  input. 
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Figure  B.1  MONITOR  Mechanism  [Bucha84,  p.  106] 
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Figure  B.2  FXNDOUT  Mechanism  [Bucha84,  p.  107] 


Note  that  FINDOUT  is  accessed  from  MONITOR,  and  MONITOR 
may  be  accessed  from  FINDOUT.  This  recursive  feature  enables 
the  generation  of  a  reasoning  network  which  is  best  suited 
for  each  patient,  and  it  also  will  cause  MYCIN  to  select  the 
necessary  questions  and  rules  to  use. 

Another  important  control  structure  is  that  FINDOUT 
doesn’t  check  whether  the  premise  of  the  rule  is  true.  It 
only  exhaustively  traces  a  parameter  and  returns  its  value 
to  MONITOR.  Then  in  MONITOR,  the  condition  may,  with  its  new 
information,  be  evaluated.  With  this  control  structure 
FINDOUT  is  called  only  once  for  each  parameter  while  MONITOR 
may  be  called  multiple  times.  Also,  when  MONITOR  reaches  the 
question  [Bucha84,  p.  106];  "HAS  ALL  THE  NECESSARY 
INFORMATION  BEEN  GATHERED  TO  DECIDE  IF  THE  CONDITION  IS 
TRUE?"  (see  figure  B.2),  the  parameter  is  then  passed  to 
FINDOUT  unless  it  is  marked  as  already  being  traced.  These 
two  features  are  what  prevents  MYCIN  from  going  into  an 
infinite  loop. 

This  concludes  the  explanation  of  MYCIN  control 
structure.  One  can  see  that  the  architecture  enables  MYCIN 
to  be  flexible  with  the  generation  of  its  inquiry,  as  well 
as  adaptive,  in  that  it  asks  only  pertinent  questions. 

DECA  also  has  a  Lookahead  Mechanism.  In  it,  DECA  tries 
to  determine  whether  other  parameters  for  a  given  scenario 
are  out  of  bounds  before  determining  if  some  of  conditions 
for  the  scenario  are  present.  Basically  it  looks  ahead  to 
see  that  all  preconditions  are  satisfied.  As  the  rules  in 
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DECA  are  nonself-referencing,  its  control  cycle  architecture 
is  not  as  complex  as  that  of  HYCIN . 

In  summary,  the  setup  of  the  Lookahead  mechanism  adds 
the  capability  for  both  DECA  and  MYCIN  to  customize  their 
"thought  process"  for  more  efficient  operation.  This  is 
important  for  DECA  since  it  is  operating  in  a  real  time 
envi ronment . 
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Appendix  C 

The  CKW  Local  Optimization  Algorithm 

This  appendix  deals  with  Jow’s  work  in  the  development 
of  the  CKW  algorithm.  Most  parts  of  this  appendix  are 
extracted  from  Jow’s  thesis  [Jow84]. 

The  motivating  factor  behind  the  CKW  algorithm  comes 
from  the  ability  to  operate  in  real-time  on  a  typical 
minicomputer  found  in  a  nuclear  power  plant  (e.g.  VAX 
11/780)  and  advise  any  maladies  in  the  system. 

In  order  to  enable  the  system  to  operate  in  real  time, 
the  CKW  algorithm  could  not  yield  a  globally  optimal 
solution  (i.e.,  an  optimal  solution  over  the  entire  problem 
space),  due  to  computational  limitations.  Thus  the 
developers  pursued  a  sub-optimal  solution  employing  Local 
Optimization  techniques. 

Jow  has  pointed  out  a  few  characteristics  of  Local 
Optimization  [Jow84,  p.  3-2]. 

1-  It  is  not  necessarily  the  globally  optimal  solution, 
though  it  can  be. 

2-  It  provides  for  an  algorithm  which  has  a  polynomial 
rate  of  increase  of  computational  complexity  with  rate 
of  growth  in  the  number  of  parameters. 

The  CKW  algorithm  was  first  proposed  by  Or.  Cynthia  K. 
Whitney  for  a  scheduling  problem  with  the  High  Energy  Laser 
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Weapon  [WhitnSI].  The  purpose  is  to  schedule  the  weapon  to 
irradiate  N  number  of  different  threats  in  a  limited  time 
period.  The  globally  optimal  solution  has  an  exponential 
increase  in  computational  complexity  with  a  linear  increase 
in  the  number  of  threats.  Thus  with  a  potentially  vast 
number  of  threats,  a  methodology  to  make  the  increase  of 
computational  complexity  of  a  polynomial  order  to  a  linear 
increase  in  the  number  of  threats  was  needed.  This  lead  to 
the  development  of  a  local  optimization. 

The  basic  features  of  the  CKW  algorithm  are 
[WhitnSI,  Jow84] : 

1-  It  decides  what  member  (parameter)  should  be  chosen 
at  each  stage  of  the  decision  immediately  after  looking 
at  one  member  beyond  the  stage  under  consideration. 

2-  At  any  stage  of  the  decision  (search),  it  looks  at 
the  performance  measure  of  each  competing  member  using 
the  satisfactory  outcome  of  the  remaining  or  pending 
members  which  have  not  been  chosen  so  far. 

3-  At  any  stage  of  the  decision  (search),  it  uses  a 
"lumped  urgency"  (a  combinatorial  argument  based  on  the 
number  of  members  that  remain  pending  and  available 
opportunities  for  them)  to  assist  in  the  selection  of  a 
member. 

The  system  will  try  to  find  the  best  solution  at  each 
stage  via  feature  one,  with  feature  two  and  three  acting  as 
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moderators  to  the  decision  process  of  the  CKW  algorithm. 

This  moderating  effect  prevents  the  CKW  algorithm  from 
making  a  too  premature  decision. 

The  CKW  algorithm  sets  up  an  algorithmic  procedure  to 
select  the  order  of  importance  of  the  parameters  of  a  system 
in  a  time  constrained  environment.  The  concepts  presented 
in  Jow’s  work  to  develop  the  CKW  algorithm  into  a  decision 
support  system  is  the  basic  motivation  factor  for  the 
development  of  the  DECA  system.  The  author  sees  a  great 
potential  in  harnessing  Artificial  Intelligence  and  Expert 
System  techniques  as  a  second  method  of  problem  solving  for 
decision  support  systems.  Eventually  both  methods  could  be 
used  in  one  system  which  could  then  take  advantage  of  both 
the  analytical  strengths  of  the  CKW  and  the  qualitative 
reasoning  ideas  of  DECA.  The  general  architecture  of  the 
DECA  system  is  designed  to  readily  facilitate  the 
integration  of  analytical  submodules  into  the  system. 


Appendix  D 
Runtime  Output  Data 
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This  appendix  contains  the  output  for  DECA’s  test  run 
and  for  the  TMI-2  accident  run. 

D. 1  Test  Run 

The  DECA  system  was  verified  to  be  working  after 
successfully  completing  the  test  run.  It  consisted  of  the 
following  three  sets  of  sensor  data  which  DECA  evaluated. 
The  sensor  data  is  shown  below: 

((05  (2150  222  606  940  160  3  940  160  558)) 

(10  (2260  270  606  870  42  1.9  910  42  635)) 

(15  (2380  282  610  870  29  0.9  860  42  635))) 

The  output  from  DECA’s  run  showing  the  values  of  the 

intermediate  variables  and  DECA’s  conclusions  is  shown 
below: 


End  of  data  evaluation  for  system  time: 
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The  parameter  and  priorities  are  as  follows: 

PZR-L  10 


PZR-P  10 
SG1-L  9.3 
SG2-L  9.3 
CL1T  8.6 
SG1P  8.5 
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0 . 2  TMI-2  Run 


The  concepts  of  the  DECA  system  were  verified  using 
actual  data  from  the  TMI-2  accident.  It  consisted  of  sensor 
data  from  nine  different  times  during  the  accident.  The 
sensor  data  shown  below  was  extracted  from  [Jow84,  pp.  5-7 
to  5-11]. 
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571 
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Intermediate  parameters  for  system  time: 
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End  of  data  evaluation  for  system  time: 
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DECA's  conclusions  for  systen  time:  30 


No  scenario  selected,  not  confident  enough. 
The  parameter  and  priorities  are  as  follows: 
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Oob-parameters-values  (1790  158  14  18) 
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102 


W  U-l 
\ 
w  M 

^  \0 

m  * 


o  m 

M  \ 


^  m 
m  w 


x 

m  w 
\ 


w  M 

X 


04  1 

Q 

W 

X  W 

\ 

M 

U 

SO 

M  <— * 

M 

SO 

J  w 

Xx 

W 

1  w 

CO 

03 

X 

m  z 

D 

04O 

\M 

in 

X  M 

m  X 

#<— s 

\ 

m 

w 

i4 

m 

\ 

1  ^ 

r- 

W\ 

w 

J 

o 

M  tJ 

W 

M 

M 

OM 

m 

z 

wz 

X  M 

in 

Q  M 

h3  9t 

2 

m 

in 

in 

1  w 

so 

M 

m 

• 

\ 

W 

w 

X  ~ 

\ 

w*p3  03 

00 

w 

o  — * 

qj 

w 

M 

w  *■» 

JZ  J 

•J 

M 

w*4 

in 

^.z 

SO 

1  1 

i 

M 

\ 

WM 

XX  M 

w 

WM 

m 

X 

04  1  O 

o 

wp 

r> 

X  w  w 

w 

win 

m 

wO  W 

r** 

\ 

\ 

w 

\ 

r*1,3 

M 

-^w 

w 

m 

*■>* 

X  t 

X 

^  ^*n 

• 

m 

1  w 

Oo 

o 

n3  • 

00 

• 

w 

xp 

w 

ZM 

M 

M  J  J  00 

OD 

04  W 

M  w 

%«< 

Z  M  M 

X  w 

X 

Z  ZJ 

J 

i-3 

r,  ^3 


wco 
r*  wo 
x 

c«  ~x 

w  as 


'O  MO 

X 

M 


W  > 
<N 


H  QuEh  W 

ZJv 

n  0»u 


ZZZK 

M 


w  i  m 

tD  m  \ 

wow 

»  W 


o  o  ~ 


o  x  r> 

M  04  W 

-  a.  w 

M  W 


«•* 

wW 

o 

M  Q 

nos 

o 

x  m  m  m 

04 

X 

o 

M 

M 

4J 

n 

M 

J 

8. 

wZ 

wM 

w 

i 

XSO  «0  n3 

X 

X 

« 

3 

wW  M 

X 

X 

MO 

04  1 

1 

1 

w 

.pz 

V 

X  03  00  X 

X 

X 

M 

(J 

«J  1-3  I 
■  I  M 
J  MO 

<oo  w 

V  W 
«  *3 
T3  J  I 

I  I  W 

2X% 

SS.~ 

C  M 
4»inn 
o  V>w 

w 


b  5^ 

M  MM 

<3  iflO 

e  o 

V  — * 

o  to 
n  au3 
1  L  ^  £P 

i  kl 


,  « 

Jcih 


U  uo 
o  o  u 
■nc  a 


1  So° 
3  c  w 
U 

«  Q 

a  w 


W  M 

w©  O  X 
M  M 
JG 

OMM 
4JHMil 
<Q  ww  9) 

B  M 

t  JJM 

0  MM  i 
M  ZZ-* 

4J  C 

0  (0 
L4  0N  O  U 
I  ww  | 

u  ww  U 

H  J 

2^2 
(ooo  3 

U  W  W  H 
*  ww3 
a  a 


04  04  « 

o.  a  i 

w  w  u 

w  w  0 

*M 

-*J  *J  I 

m  co  w 

M  M  0 


SI  |  £ 

*  3  « 
M  H  w 
<o  3  b 
a.  a  £ 


M 

C0  4J  4J 

>4  0  m 

CO  C  Sm 


«  9 

e  u  xjjj 

a>  <0  I  I  I  I 

u  a  xxmw 

CO  04  04  o  O 

a  xx  w  w 


§  £  i 


Scenarios  that  were  considered  as  possible  choices  but  not 
selected  are: 


Pipe  Rupture  -  (drain  tank) 
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Pirameter-rank-list  ((PZR-L  10)  (PZR-P  10)  (SG2-L  8.5)  (SG1-L  8.5)) 
Parim.*ter-rank-list  ((PZR-P  PZR-L  10)  (SG1-L  SG2-L  8.5)) 
Para»eter-rank-llst  ((PZR-P  10)  (PZR-L  10)  (SG1-L  8.5)  (SG2-L  8.5)) 


Poss ible-scenar los- for-s i tuatlon  ((3  2/3)  (1  2/3)  (2  4/7)  (11  2/5)  (10  2/5)  (6  2/5)  (5  2/5)  (8  1/3)  (4  1/3)) 
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Scenarlo-data-natch-llst  ((1  (SG2-L  SG1-L  PZR-L  PZR-P))  (2  (SG2-L  SG1-L  PZR-L  PZR-P))  (3  (PZR-L  PZR-P))  (4  (PZR- 
(5  (SG2-L  SG1-L) )  (6  (SG2-L  SG1-L))  (7  NIL)  (8  (SG2-L  SG1-L))  (9  NIL)  (10  (SG2-L  SG1-L) ) 

(11  (SG2-L  SG1-L))  (12  NIL)) 
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APPENDIX  E 

DECA  Knowledge  Base  for  TMI-2  Accident 

This  appendix  contains  both  explanations  and  a  listing 
of  the  various  data  files  which  were  employed  by  DECA  to 
give  it  the  knowledge  about  the  nuclear  reactor  for  the 
Three  Mile  Island  Unit  2  nuclear  accident. 

DECA  is  designed  to  be  a  generic  system,  thus  its 
inference  engine  and  knowledge  base  must  be  separate.  In 
order  to  use  DECA  on  a  different  process,  one  will  just  have 
to  load  up  the  new  data  and  not  have  to  make  any  changes  to 
the  computer  code.  Appendix  E  contains  the  knowledge  base 
files  listings  and  Appendix  F  contains  the  inference  engine 
1 isting. 

A  schematic  diagram  showing  the  components  of  the  TMI-2 
reactor  is  shown  in  figure  E.l. 


Atmospheric  -v  _  . 

dump  valve  \  SB,ety  Ma,n  a,aam 

Conlainmeol  building  \vatvee  isolalion  valve  (A) 


Figure  E.1  TMI-2  Schematic  [NSAC-1,  appendix  C/FDW] 


E.1  Scenario-description. d  :a  File 


Listed  below  is  the  data  file  which  gives  the  scenario 
numbers  and  a  description  of  the  scenario  for  the  TMI-2 
runs.  For  example,  scenario  3  is  the  scenario  where  there  is 
a  pipe  rupture  in  the  drain  tank  in  the  TMI  reactor.  These 
descriptions  are  assigned  since  DECA  is  meant  to  work  with  a 
variety  of  processes,  and  thus  there  must  be  some  specific 
tags  assigned  to  the  scenario  numbers  to  enable  DECA  to 
interface  with  the  system  operators. 


((1  "Pressurizer  Leak  ") 

(2  "Block  Valve  Leak  ") 

(3  "Pipe  Rupture  -  (drain  tank)  ") 

(4  "Drain  Tank  ") 

(5  "Pipe  Rupture  -  Hot  Leg,  Primary  Coolant  System  ") 
(6  "Pipe  Rupture  -  Cold  Leg,  Primary  Coolant  System  ") 
(7  "Reactor  Pump  ") 

(8  "Steam  Generator  -  Primary  Coolant  System  ") 

(9  "Steam  Generator  -  Secondary  Coolant  System  ") 

(10  "Pipe  Rupture  -  Secondary  Coolant  System  “ ) 

(11  "Feedwater  Pump  -  Secondary  Coolant  System  ") 

(12  "Turbine  Trip  -  Secondary  Coolant  System  “) 

) 
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E.2  Parameter-expect . data  File 

This  data  file  is  used  by  DECA  to  determine  the  rank  of 
the  parameters.  DECA  checks  to  see  what  scenarios  match  up, 
and  gives  a  rank  according  to  the  template  given  below.  The 
list  contains  several  sublists  patterned  in  the  following 
manner: 

(  (parameter  (rank  ( corresponding  match  list  for  the  rank)) 
(rank  (number  of  scenarios  needed  for  rank))) 

) 

For  example,  for  the  following  parameter  QNT-P: 

(QNT-P  ((10  (2  3  4)) 

(9.5  (2  4)) 

(8.5  (2  3)) 

(8  (3  4))  ) 

((4.3  1)  )) 

one  can  see  that  to  have  a  rank  of  10,  the  scenarios  2,  3, 
and  4  must  be  considered  as  possibilities  by  DECA.  Also,  if 
only  scenarios  3  and  4  are  a  possibility,  then  DECA  will 
give  QNT-P  a  rank  of  8.  The  second  sublist  is  the  hybrid 
part.  In  it  one  can  see  that  if  any  one  scenario  (not 
scenario  1)  from  the  list  of  scenarios  for  rank  10  is  a 
possibility,  then  give  QNT-P  a  rank  of  4.3. 

The  second  sublist  of  ranks  is  to  prevent  the  need  to 
list  every  possible  combination  of  scenarios  for  each 
parameter  (combinatorial ly  explosive  and  computationally 
impossible  if  there  are  many  scenarios  in  a  large  system). 
For  example,  if  there  were  100  parameters  for  the  system 
under  evaluation  and  on  average  there  were  50  scenarios 
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associated  with  each  parameter,  then  there  would  be  in  the 

6  6 

neighborhood  of  501*100  or  3.0414*10  combinations.  This  is 
clearly  unacceptable  from  a  computational  standpoint. 
Employing  the  hybrid  system  of  reference,  the  system  looses 
some  subtle  interrelationships  between  scenarios  and 
parameters,  but  for  the  100  parameter  case  there  will 
probably  be  only  80  matches  to  make  per  parameter  or  8000 
total.  See  the  function  MAKE-PARAMETER-RANKING  in  the  source 


code  (Appendix  F)  for  further  explanation  of  the  hybrid 


system. 

Below  is  the  data  file  contents  of  the  expectancies  for 

all  parameters  used  in  the  TMI-2  test  run. 

(  ( PZR-P  ((10  (1234)) 

(8.5  (2  3  4)) 

(8.5  (1  3  4)) 

(6  (1  2  3)) 

(6  (1  2  4))  ) 

( 

(4  2) 

(2.2  1)  )) 

(PZR-L  ((10  (1234)) 

(8.5  (2  3  4)) 

(8.5  (1  3  4)) 

(6  (1  2  3)) 

(6  (1  2  4))  ) 

( 

(4  2) 

(2.2  1  )  )) 

(HL1-T  ((10  (6  7  8)) 

(8.5  (6  7)) 

(8.5  (6  8)) 

(7  (7  8))  ) 

( 

(3  1)  )) 

( SGI -P  ((10  (1  2  5  6  7  8  9  10  11  12)) 

(9.8  (125678)) 

(8.5  (1256  7)) 

(8.5(12568))  ) 

( 

(9  9) 

(8.5  8) 

(8.2  7) 
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(8  6) 

(6  5) 

(5  4) 

(3  3) 

(2  2) 

(11)  )) 

( SGI -L  ((  10  (  1  2  5  6  8  9  10  1  1  12)) 
(9.8  (1256  8)) 

(9  (125  6))  ) 

( 

(9.3  8) 

(8.5  7) 

(7.5  6) 

(6  5) 

(4  4) 

(3  3) 

(1.5  2) 

(1  1  )  )) 

(QNT-P  ( (  10  (2  3  4)  ) 

(9.5  (2  4)) 

(8.5  (2  3)) 

(8  (3  4))  ) 

( 

(4.3  1)  ) ) 

( SG2-P  ((10  (12  56  7  89  10  11  12)) 

(9.8  (125678)) 

(8.5  (1256  7)) 

(8.5  (12568))  ) 

( 

(9  9) 

(8.5  8) 

(8.2  7) 

(8  6) 

(6  5) 

(5  4) 

(3  3) 

(2  2) 

(11)  )) 

(SG2-L  ((10  (1  2  5  6  8  9  10  11  12)) 
(9.8  (1256  8)) 

(9  (125  6))  ) 

( 

(9.3  8) 

(8.5  7) 

(7.5  6) 

(6  5) 

(4  4) 

(3  3) 

(1.5  2) 

(1  D 


)) 
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(CL1-T  ( (10  (5  7  8  9  10  11  12) ) 
(9.6  (578  9)) 

(9  (5  7  8)) 

(6  (5  7))  ) 

( 

(9.2  6) 

(8.6  5) 

(8  4) 

(4  3) 

(2.5  2) 

(1  1  )  )) 
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E.3  Scenario-tendency .data  File 


The  file  scenario- tendency . data  contains  the  system 
knowledge  of  the  expected  parameter  tendency  for  a  given 
scenario  to  be  true.  The  better  the  expected  tendencies 
match  the  sensor  data,  the  more  likely  that  the  scenario  is 
actually  occurring. 

For  example,  suppose  that  from  the  Lookahead  Mechanism, 

DECA  suspects  that  scenario  number  4  is  possibly  occurring. 

To  verify  this  DECA  looks  at  the  required  tendencies  of  the 

parameters  associated  with  scenario  4. 

(4  ( ( PZR-P  LOWER) 

( P2R-L  HIGHER) 

(QNT-P  HIGHER) 

)) 

For  TMI-2  that  would  be  PZR-P  would  be  lower  than  the 
setpoint  value,  and  PZR-L  and  QNT-P  would  both  be  running 
higher  than  their  setpoint  values.  If  everything  matches  up 
then  scenario  4  would  be  considered  one  of  the  more  likely 
explanations. 

Below  is  the  listing  of  the  scenario- tendency . data  file 
used  for  the  TMI-2  runs  on  the  DECA  system. 

(  (1  (  (PZR-P  LOWER) 

(PZR-L  LOWER) 

( SGI -P  LOWER) 

(SG1-L  LOWER) 

( SG2-P  LOWER) 

( SG2-L  LOWER))) 

(2  (  (PZR-P  LOWER) 

(PZR-L  LOWER) 

( SG1-P  LOWER) 

( SG1-L  LOWER) 

(QNT-P  HIGHER) 

( SG2-P  LOWER) 

(SG2-L  LOWER))) 
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(3 

( 

( PZR-P 

LOWER ) 

(PZR-L 

LOWER) 

( QNT-P 

LOWER) ) ) 

(4 

( 

(PZR-P 

LOWER) 

(PZR-L 

HIGHER) 

(QNT-P 

HIGHER) ) ) 

(5 

( 

(SG1-P 

LOWER) 

( SGI -L 

LOWER) 

( SG2-P 

LOWER) 

( SG2-L 

LOWER ) 

(CL1-T 

LOWER) ) ) 

(6 

( 

(HL1-T 

HIGHER) 

( SGI -P 

HIGHER) 

( SGI -L 

LOWER) 

( SG2-P 

HIGHER) 

( SG2-L 

LOWER) ) ) 

(7 

( 

(HL1-T 

HIGHER) 

( SGI -P 

HIGHER) 

( SG2-P 

HIGHER) 

(CL1-T 

HIGHER) ) ) 

(8 

( 

(HL1-T 

HIGHER) 

(SG1-P 

LOWER) 

( SGI -L 

LOWER) 

(SG2-P 

LOWER) 

( SG2-L 

LOWER ) 

(CL1-T 

HIGHER) ) ) 

(9 

( 

( SGI -P 

HIGHER) 

(SG1-L 

HIGHER) 

(SG2-P 

HIGHER) 

( SG2-L 

HIGHER) 

(CL1-T 

HIGHER) ) ) 

(10 

( 

(SG1-P 

HIGHER) 

( SGI -L 

LOWER ) 

( SG2-P 

HIGHER) 

( SG2-L 

LOWER) 

(CL1-T 

HIGHER) ) ) 

(11 

( 

( SGI -P 

HIGHER) 

(SG1-L 

LOWER) 

( SG2-P 

HIGHER) 

( SG2-L 

LOWER) 

(CL1-T 

HIGHER) ) ) 

(12 

( 

( SGI -P 

LOWER ) 

( SGI -L 

HIGHER) 

( SG2-P 

LOWER) 

( SG2-L 

HIGHER) 

(CL1-T 

HIGHER) ) ) 
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E . 4  Scenario. data  File 


This  data  file  contains  all  the  parameters  of  the 
process  which  DECA  is  monitoring.  For  each  parameter,  there 
follows  a  list  of  scenarios  which  must  be  evaluated  if  that 
parameter  is  marked  as  being  out  of  bounds.  This  list  of 
scenarios  is  accessed  by  DECA’s  lookahead  mechanism. 

For  example,  if  the  evaluation  of  the  sensor  data  for 
parameter  PZR-P  has  determined  that  it  is  beyond  its 
setpoint  values  (and  marked  as  out  of  bounds),  then  DECA 
will  access  this  data  and  determine  that  it  must  check 
scenarios  1,  2,  3,  and  4  as  being  possible  events  occurring 
in  the  process. 


PZR-P 

(1234) 

PZR-L 

(1234) 

HL1-T 
(6  7  8) 

SGI  -P 

(1  2  5  6  7  8  9  10  11  12) 
SGI  -L 

(1  2  5  6  8  9  10  11  12) 

QNT-P 

(3  4) 

SG2-P 

(1256789101112) 

SG2-L 

(1  2  5  6  8  9  10  11  12) 
CL1-T 

(5  7  8  9  10  11  12) 
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E.5  Setpoint. data  File 


This  file  contains  the  values  for  each  of  the  process 
parameters  setpoints.  DECA  uses  these  setpoints  to  determine 
if  the  system  parameter  is  in  a  normal  operating  state  or  if 
it  is  abnormal.  If  abnormal,  DECA  also  uses  the  data  to 
determine  what  is  the  severity  of  the  parameter. 

The  first  element  of  the  file  indicates  the  number  of 
parameters  in  the  system.  Next  listed  is  the  parameter,  then 
its  setpoint  mode  (e.g.  normal  here).  There  can  be  more 
than  one  setpoint  database  on-line.  The  one  used  would 
correspond  to  systems  operating  condition  (e.g.  normal, 
reactor  shutdown,  refueling).  Next  listed  is  the  units  of 
measure  of  the  data,  and  finally  a  list  of  the  seven 
different  setpoint  values. 

The  data  for  the  TMI-2  shown  below  was  obtained  from 
[ Jow84] . 


9 

PZR-P 

NORMAL 

PSIG 

(1200  1900  2055  2150  2250  2355  2400) 

PZR-L 

NORMAL 

INCHES 

(  45  150  200  222  240  260  280) 

HL1-T 

NORMAL 

F 

(  300  400  500  606  610  619  630) 

SGI  -P 

NORMAL 

PSIG 

(  800  850  900  940  1050  1070  1105) 
SG1-L 
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NORMAL 

INCHES 

(  10  30  45  160  170  180  190) 

QNT-P 

NORMAL 

PSIG 

(  1  2  2.5  3  35  80  122) 

SG2-P 

NORMAL 

PSIG 

(  800  850  900  940  1050  1070  1105) 

SG2-L 

NORMAL 

INCHES 

(  10  30  45  160  170  180  190) 

CL1-T 

NORMAL 

F 

(  300  400  500  558  610  619  630) 
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E.6  Sensor. data  File 

The  sensor. data  file  contains  the  actual  measurements 
from  the  TMI-2  accident  [Jow84].  The  format  is  as  follows; 
each  line  represents  one  time  step,  the  first  element  in 
the  list  is  the  time,  and  the  sublist  is  the  readings  for 
each  of  the  nine  parameters  being  monitored.  The  time  is  the 
seconds  after  turbine  trip  during  the  accident.  The  sensor 
data  is  always  read  in  in  the  same  order:  PZR-P,  PZR-L, 
HL1-T,  SGI -P,  SG1-L,  QNT-P,  SG2-P ,  SG2-L,  CL1-T. 


(  (0  (2145  218  607 

(15  (2260  253  61 1 

(30  (1905  182  587 

(45  (1855  160  579 

(60  (1790  158  578 

(75  (1760  162  577 

(90  (1725  175  578 

(105  (1685  187  579 
(120  (1650  200  579 


944 

123 

3 

930 

116 

559)  ) 

1022 

79 

6.3 

1012 

80 

571  )  ) 

998 

26 

7.8 

987 

30 

577)  ) 

1000 

17 

9.3 

993 

20 

576)) 

990 

14 

12 

969 

18 

576  )) 

101 1 

10 

14.3 

997 

16 

576)) 

1023 

11 

17.5 

1005 

16 

577  )) 

1021 

1 1 

19.6 

1005 

16 

577  )) 

101 1 

1 1 

22.2 

1000 

16 

579)  ) 
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Appendix  F 

DECA  Program  Listing 

This  appendix  contains  the  source  code  for  the  DECA 
system. 
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; ; ; 
; ; ; 
; ;  / 
; ; ; 
; ;  / 
/  /  / 
it! 
; ;  ; 
;  /  / 
i  !  i 
; ; ; 
i  !  i 
; ; ; 
/ ;  / 


; ; ; 
/ ; ; 


Mode:  LISP/  Syntax:  Coomon-liap;  Package:  USER;  Base:  10 


PROGRAMMER: 

FILE: 

DATE: 

LANGUAGE: 

MACHINE: 

OPERATING  SYSTEM: 
COMMENTS : 


Steven  R .  Nann 
h: >srn>thesis>deca . lisp 
Jan  -  Mar  1988 

Symbol ics-Comoon- Lisp  with  Flavors 
Symbolics  3670 
Genera  7 . 1 

This  is  the  kernel  of  the  DECA  system 
software. 


/  /  /■ 
; ; ; 

;  /  / 

; ;  / 

; ;  /  • 
; ;  / 

;  /  / 

;  /  / 

;  / ; 

; ;  ; 

; ; ; 

; ; ; 

; ;  / 

; ; ; 

/  / 1 
; ; ; 
III' 
I  1  I 
1  1  I 
i  / / 
; ; ; 
ill 
1 1 1 
1 1 ; 

1 1 1 
1 1 1 
i  1 1 
1 1 1 
1 1 1 
1 1 1 
1 1 1 
1 1 1 
/ 1  / 
; ;  i 
1 1 1 
1 1 1 
; ; ; 
; ; ; 
tit 
1 1 1 
1 1 1 
1 1 1 
i ; ; 
;  1 1 
1 1 1 
1 1 1 


COPYRIGHT  1988  -  ALL  RIGHTS  RESERVED 


The  DECA  system  Is  an  Expert  System  for  real  time  process  control 
during  routine,  emergency  and  time  constrained  situations. 

This  Inference  Engine  Is  built  as  a  generic  one  for  any  dynamic 
domain.  The  refemces  of  the  parameters  and  scenarios  just 
HAPPEN  to  be  from  the  domian  vhich  DECA  was  tested.  One  will 
find  no  refence  within  the  program  to  any  THI-3  parameter  or 
scenario  except  maybe  in  the  comments  where  an  example  of  a 
Lisp  structure  is  given  and  the  three  generate  lisp  forms. 


Input  parameters  for  the  THI-3  accident  test  scenario 

SYS-TIHE  System  time 
PZR-P  Pressurizer  Pressure 

PZR-L  Pressurizer  Level 

HL1-T  Hot  Leg  1  Temperature 
SGI— P  Steam  Generator  1  Pressure 

SGI— L  Steam  Generator  1  Level 

QNT-P  Drain  Tank  Pressure 
SG3-P  Steam  Generator  3  Pressure 

SG3-L  Steam  Generator  3  Level 

CL1-T  Cold  Leg  1  Temperature 

Scenario  numbers  and  descriptions . 

I  Pressurizer  Leak 
3  Block  Valve  Leak 

3  Pipe  Rupture  -  (drain  tank) 

4  Drain  Tank 

5  Pipe  Rupture  -  Hot  Leg,  Primary  Coolant  System 
fi  Pipe  Rupture  -  Cold  Leg,  Primary  Coolant  System 

7  Reactor  Pump 

8  Steam  Generator  -  Primary  Coolant  system 

9  steam  Generator  -  Secondary  Coolant  System 

10  Pipe  Rupture  -  Secondary  Coolant  system 

II  Feedwater  Pump  -  Secondary  Coolant  system 
13  Turbine  Trip  -  Secondary  Coolant  system 


iii  Define  the  system  (global)  variables: 


( DEFVAR 
(DEFVAR 
(DEFVAR 
(  DEFVAR 
(DEFVAR 
( DEFVAR 
(DEFVAR 
(DEFVAR 


TEHP- IO-DATA  NIL) 
SENSOR-DATA  NIL) 
SYS-TIHE  NIL) 
SENSOR-RECORD  NIL) 
OPERATION-FLAG  ’NORHAL) 
PAR AH -NUN  NIL) 
SETPOINT-DATA  NIL) 
SDB-LIST  NIL) 


/total  inputs 
/cdr's  inputs 


of  all  data 


/parameter. 


,-time  of  sensor  data 
/data  for  one  time  step 
/flag  for  operating  cond 
; number  of  system  parameters 
/var  of  all  setpoint  data 
/list  of  all  setpoint  data  by 


(DEFVAR  OOB- PARAMETERS  NIL) 

(DEFVAR  OOB— SEVER ITY  NIL) 

(DEFVAR  OOB-PARAMETERS-VALUES  NIL) 

(DEFVAR  SCENARIO-LIST  NIL) 

(DEFVAR  LOOKAHEAD-SCENARIOS  NIL) 


/out  of  bounds  parameters 
/severity  list  of  oob's 
/sensor  value  for  oob  params. 

, paraa/scenario  lookahead  list 
/scenarios  to  be  checked  out 


(DEFVAR  SCENARIO-EXPECTANCY  NIL)  / param  tendencies  for  each  scenario 

(DEFVAR  PARAMETERS-PER-SCBNARIO-EXPECT  NIL)  / I  of  expected  params,  all  seen. 
(DEFVAR  SCENARIO— DATA— hATCH-LIST  NIL)  /scenario  i  a  params  vhich  match 

/with  the  expected  tendency  in  scenario-expectancy 
(DEFVAR  SCENARIO-RATIO-MATCH-LIST  NIL)  /contains  seen  I ,  ratio,  qual  value 

/eg  (  (1  0.6  minor)  ....) 

(DEFVAR  PARAMETER-EXPECTANCY  NIL)  /param,  rank  1-10,  and  scenario  combinations 

/  which  will  give  the  param  that  rank. 

(DEFVAR  PARAMETER-RATIO-MATCH  NIL)  /list  of  lists  of  (parameter  ratio) 

/where  ratio  is  the  Iscenario  match/lscenario  expected. 
(DEFVAR  SCENARIO-MAJOR  NIL) 

(DEFVAR  SCENARIO-MINOR  NIL) 

(DEFVAR  SCENARIO-IMPROBABLE  NIL) 


(DEFVAR  PARAMETER-RANK-LIST  NIL) 

(DEFVAR  POSSIBLE-SCENARIO-FOR-SITUATION  NIL) 
(DEFVAR  SCENARIO-DESCRIPTION  NIL) 


(DEFVAR  FILE-SPEC  NIL) 

(DEFVAR  OUTPUT- FILE-NAME  NIL) 


/  /  /  ———————————— 

#;;  first  read  in  the  sensor  data: 

i ,  i  ---- — — -------- 


it  Bring-ln-system-data  will  read  in  the  data  for  DECA's  run. 

(DEFUN  BRING— IN— SYSTEM-DATA  (INPUT-FILE)  / BRING-IN-SYSTEM-DATA 

(LET  ( (TEMP— IO-DATA-LIST) 

) 

(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 

(WITH-OPEN-FILE  (SENSOR-INPUT  INPUT-FILE 
.-DIRECTION  :  INPUT 
: CHARACTERS  T) 

(SETQ  TEMP- IO-DATA-LIST  (READ  SENSOR- I NPUT ) ) 

) 

//(FORMAT  T  "“%  DATA  INPUT  SUCESSFULLY  *»") 

(SETQ  SENSOR-DATA  TEMP- IO-DATA-LIST ) ) 

/(FORMAT  T  "SENSOR  DATA  IMPORTED  SUCCESSFULLY.  “%") 

) 


,- /  Set  up  the  setpoint  database  -  instances 


it  Read  in  the  Setpoint  Database  which  are  stored  in  the  files 
//  h: >sra > thesis isetpoint . data 


( DBFFLAVOR  SDB  (PARAMETER 
MODE 
UNITS 
LLL 
LL 
L 
N 
H 

HH 

HHH) 

() 

: READABLE- I NSTANCE-VAR I ABLES 
: WRITABLE-INSTANCE-VARIABLES 
: INI (ABLE- INSTANCE- VARIABLES ) 

(DEFFLAVOR  SDB- ALL  (OPERATING-MODE 
DATA-LIST) 

() 

: READABLE- INSTANCE-VARIABLES 
: WRITABLE- INSTANCE— VARIABLES 
: INITABLE-INSTANCE-VARIABLES) 
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(DEFUN  MAKE -SET POINT -DAT ABASE  ( INPUT-PILE) 

(LB T  ( (TUP— DAT A-LIST) 

(TMP-PARAM) 

( TMP -MODE ) 

( TMP-tJNIT) 

(SDB-PARAM) 

) 

(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 
(WITH-OPEN-FILE  ( SDB-DATA  INPUT-FILE 
: DIRECTION  : INPUT 
: CHARACTERS  T) 

(SETQ  PARAM-NUM  (READ  SDB-DATA)) 

(DOTIMES  (I  PARAM-NUM) 

(SETQ  TMP-PARAM  (READ  SDB-DATA) 

TMP— MODE  (READ  SDB-DATA) 

TMP-UNIT  (READ  SDB-DATA) 
TMP-DATA-LIST  (READ  SDB-DATA)) 

(SETQ  SDB-PARAM 

( MAKE - I NSTANCE  1 SDB 


PARAMETER 

TMP-PARAM 

MODE 

TMP-MODE 

UNITS 

TMP-UNIT 

LLL 

(NTH 

0  TMP-DATA-LIST) 

LL 

(NTH 

1  TMP-DATA-LIST) 

L 

(NTH 

2  TMP-DATA-LIST) 

N 

(NTH 

3  TMP-DATA-LIST) 

H 

(NTH 

4  TMP-DATA-LIST) 

HH 

(NTH 

5  TMP-DATA-LIST) 

HHH 

(NTH 

6  TMP-DATA-LIST))) 

(SETQ  SDB-LIST  (CONS  SDB-PARAM  SDB-LIST)) 

/ (DESCRIBE  SDB-LIST) 

) 

(SETQ  SDB-LIST  (REVERSE  SDB-LIST)) 

(SETQ  SETPOINT-DATA  (MAKE-INSTANCE  1 SDB-ALL 

: OPERATING-MODE  TMP-MODB 
.-DATA-LIST  SDB-LIST)) 

; (DESCRIBE  SETPOINT-DATA) 

) 

) 

) 


ill  Setup  the  Parameter/Scenario  Database  for  the  Lookahead  Mech. 

(DEFFLAVOR  SCENARIO  (PARAMETER 
SCENARIOS) 

O 

: READABLE-INSTANCE-VARIABLES 
: WRITABLE-INSTANCE-VARIABLES 
! INITABLE- INSTANCE— VARIABLES) 

(DEFUN  MAKE-PARAMETER-SCENARIO-DATABASE  (INPUT-FILE) 

(LET  ( (TEMP-PARAM) 

(TEMP-SCENARIO) 

(TEMP-SCENARIO-LIST) 

) 

(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 

(WITH-OPEN-FILE  (SCENARIO-INPUT  INPUT-FILE 

:  DIRECTION  .-INPUT 
: CHARACTERS  T) 

(DOTIMES  (I  PARAM-NUM) 

(SETQ  TEMP-PARAM  (READ  SCENARIO-INPUT) 

TEMP-SCENARIO  (READ  SCENARIO-INPUT)) 

(SETQ  TEMP-SCENARIO-LIST  (MAKE-INSTANCE  'SCENARIO 

: PARAMETER  TEMP-PARAM 
.-SCENARIOS  TEMP-SCENARIO)) 
(SETQ  SCENARIO-LIST  (CONS  TEMP-SCENARIO-LIST 

SCENARIO-LIST) ) 

) 

(SETQ  SCENARIO-LIST  (REVERSE  SCENARIO-LIST)) 

)) 


i i ;  Compare  the  sensor  data  with  the  setpoint  database 

lit  Bod  determine  oob  parameters  a  associated  severity. 

ill  Code  correlates  to  moat  of  DECA  -  diagnostic  level  l'a  purpose. 


ii  Used  when  multiple  setpoint  databases.  Will  retrieve  the 
it  appropriate  database  depending  on  the  operation-flag. 

(DEFMETHOD  ( GET— SDB  SDB-ALL)  (OPERATION-FLAG)  ;GET~SDB 

(COND  ( ( EQUAL  ( SDB-ALL-OPERATING-MODE  SELF)  OPERATION-FLAG) 
(SDB— ALL-DATA-LIST  SELF)) 

) 

) 


; ;  Used  to  check  whether  the  parameter  is  out  of  bounds 

(DEFMETHOD  (CHECK-OOB  SDB)  ( PARAM-THP- VALUE )  ; CHECK-OOB 

(FLAG-RULE  LLL  LL  L  H  HH  HHH  PARAMETER  PARAM-TMP-VALUE ) ) 

ii  This  checks  and  records  oob  parameters,  their  values,  and 
ii  calls  the  function  to  determine  the  severity. 

/  / 

( DEFUN  FLAG-RULE 

(LLL  LL  L  H  HH  HHH  PARAM  PARAM-TMP-VALUE) 

(COND  ({OR  (<  PARAM-TMP-VALUE  L) 

(>  PARAM-TMP-VALUE  H)) 

(SETQ  OOB-PARAMETERS 

(CONS  PARAM  OOB-PARAMETERS) 

OOB-PARAMETERS-VALUES 

(CONS  PARAM-TMP-VALUE  OOB-PARAMETERS-VALUES)) 

( SEVERITY-RULE  PARAM-TMP-VALUE  LLL  LL  L  H  HH  HHH) 

)) 

) 


i i  This  will  update  the  list  of  the  severities  which  correlate  to 
ii  the  parameters  in  oob-parameters  list. 

1 1 

{DEFUN  SEVERITY-SET-TO  (O-VALUE)  /SEVERITY-SET-TO 

(SETQ  OOB— SEVERITY  (CONS  Q-VALUE  OOB-SEVERITY)  )  ) 


ii  This  fuction  determines  the  level  of  severity  (eg  LL) 
ii  and  calls  severity-set-to  function  to  update  the  list. 


1 1 

(DEFUN  SEVERITY-RULE  (DATA  LLL  LL  L  H  HH  HHH) 
(COND  ((<-  DATA  L) 

(COND  ((>  DATA  LL) 

((>  DATA  LLL) 

((<-  DATA  LLL) 

( ( >-  DATA  H) 

(COND  ((<  DATA  HH) 

((<  DATA  HHH) 

((>-  DATA  HHH) 


( SEVERITY-SET-TO 
(SEVERITY-SET-TO 
( SEVERITY-SET-TO 

( SEVER ITY-SBT-TO 
( severity-set-to 

(SEVERITY-SET-TO 


'L>> 

'  I»L)  ) 

'LUO))) 

'H)> 

'HH)) 

'HHH)))))) 


/SEVERITY-RULE 


; ;  This  function  is  the  top  level  controller  for  the  comparison  of  sensor 
ti  data  and  the  values  in  the  setpoint  database.  Its  purpose  is  to  determine 
ti  the  oob  parameters  and  their  level  of  severity  for  the  given  instant  in  time. 

; ; 

(DEFUN  COMPARE-SENSOR-DATA  (S-DATA  SETPOINT-DATA) 

(LET  ( (TEMP— DATA— LIST) 

( PARAM-TMP-VALUE ) 

( PARAM— SETPOINT— LIST) 

) 

(SETQ  TEMP-DATA— LIST  SDB-LIST) 

(DOTIMES  (I  PARAM-NUM) 

(SETQ  PARAM-TMP-VALUE  (NTH  I  S-DATA) 

PARAM-SETPOINT-LIST  (NTH  I  TEMP-DATA-LIST) ) 

(CHECK-OOB  PARAM-SETPOINT-LIST  PARAM-TMP-VALUE) 

) 

> 

(SETQ  OOB-PARAMETERS  (REVERSE  OOB-PARAMETERS) 

OOB-PARAMETERS-VALUES  (REVERSE  OOB-PARAMETERS-VALUES) 

OOB-SEVERITY  (REVERSE  OOB-SEVERITY)) 

) 
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; ; /  Gathering  Lookahead  scenario  data 

; ;  This  function  will  take  the  scenarios  given  and  run  thru  the  list 
ii  and  add  any  scenario  not  In  lookahead-scenarios  list.  It  will  then 
;;  sort  the  acenalos  from  smallest  to  largest. 

/  / 

(DEF0N  CHECK— SCENARIO— HERE  (SCENARIOS-PICKED) 

( DOLIST  (I  SCENARIOS-PICKED  ) 

(COND  ((NOT  (MEMBER  I  LOOKAHEAD-SCENARIOS ) ) 

( SETQ  LOOKAHEAD-SCENARIOS 

(CONS  I  LOOKAHEAD-SCENARIOS)) 

))  ) 

(SETQ  LOOKAHEAD— SCENARIOS  (SORT  LOOKAHEAD-SCENARIOS  #'<)) 

;; (FORMAT  T  “"%lookahead-scenarioa  “a  “  LOOKAHEAD-SCENARIOS) 

) 


; ;  The  function  get-scenarios  retrieves  scenarios  for  lookahead 
;;  mechanism.  Input  ->  oob-parameters  list  (locally  its  oob-key) 

< ;  checks  with  the  instances  of  scenarios  in  the  scenario-list 
;;  and  pulls  all  scenarios  for  each  oob  parameter.  These  will  then 
li  be  combined  in  one  list  (ie  no  repeats)  with  check-scenario-here 
it  function. 

;;New  version 

(DEFUN  GET-SCENARIOS  (OOB-KEY) 

(DOLIST  (I  OOB-KEY) 

(DOLIST  (J  SCENARIO-LIST) 

( GET— SCENAR IOS— 1  J  I) 

> 

) 

) 

(DEFMETHOD  (GET-SCENARIOS-1  SCENARIO)  ( TEMP -OOB-P ARAM) 

(LET  ((TEMP-PARAMETER  PARAMETER) 

(TEMP-SCENARIOS  SCENARIOS) 

) 

(COND  ( (EQUAL  TEMP “PARAMETER  TEMP— OOB-P ARAM) 

;s (format  t  "“%  temp-scenarios  "a"  temp-scenarios) 
(CHECK-SCENARIO-HERE  TEMP-SCENARIOS) 

)) 

) 

) 

i  * 

; ;  After  the  above  method  is  run  all  the  scenarios  that  are  needed  for 
; ;  the  lookahead  mechanism  are  contained  in  the  global  parameter 
; ;  lookahead-scenarios . 


til  Functions  for  Lookahead  to  see  if  the  sensor  data  matches 
in  up  with  any  of  the  scenario's  expectations.  It  is  done  for 
ill  each  scenario  contained  in  the  global  list  lookahead-scenarios. 


ii  Bring  in  the  scenario  expectancy  (tendency)  data.  It  will  come 
ii  in  in  the  form  of  lists.  One  list/scenario.  They  will  be  put 
ii  into  one  global  list  scenario-expectancy.  This  list  will  be  used 
; ;  for  all  the  checking  of  match-up  through  the  prioritizer  portion 
ll  Of  DECA. 

(DEFUN  MAKE-SCENARIO-EXPECTANCY  (INPUT-FILE) 

(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 

(WITH -OPEN-FILE  (TENDENCY-INPUT  INPUT-FILE 

i DIRECTION  : INPUT 
: CHARACTERS  T) 

(SETQ  SCENARIO-EXPECTANCY 
(READ  TENDENCY-INPUT)) 

) 


) 


ii  The  oaxt  part  vill  be  to  check  the  senaor-data  with  agaiost  the 
ii  expectancy  of  DEC*.  It  will  use  the  lists  scenario-expectancy 
it  and  lookahead-scenarios  as  well  as  oob-parameters  and 
/;  oob-aeverity .  If  the  sensor  data  for  the  parameter  matches 
ii  up  with  the  expectancy,  then  the  parasteter  is  added  to 
ii  the  list  of  suitches  for  that  scenario. 

( DEPUN  HATCH -SCENARIO-TENDENCY  () 

(DOLIST  (I  LOOKAHEAD-SCENARIOS) 

(DOLIST  (J  SCENARIO-EXPECTANCY) 

(LET  (  ( TEMP-NUM  (CAR  J)  ) 

(TEMP-EXPECT  (CADR  J)) 

> 

(IP  ( EQUAL  I  TEMP— NUM) 

(DOLIST  (X  TEMP-EXPECT) 

(LET*  ( (TEMP1-PARAMETER  (CAR  K) ) 
(SCENARIO-EXPECTANCY-DATABASE-DATA  (CADR  K) ) 

(TEMP2  (MEMBER  TEMP 1-PARAMETER  OOB-PARAMBTERS ) ) 

(TEMP-COUNT) 

) 

ii  Now  set  the  index  so  know  where  to  look  in  the  oob-severity  list. 
ii  Note  the  oob-severity  list  cats  directly  corresponds  to  the 
ii  parameter  at  the  same  location  in  the  oob-parameter  list. 

;  i 

(COND  (TEMP2 

(SETQ  TEMP-COUNT  (-  (LENGTH  OOB-PARAMBTERS) 

(LENGTH  TEMPS) ) ) 

; ; Now  go  retrieve  the  tendency  from  the  oob-severity  list. 
//There  are  only  2  tendencies,  higher  or  lower. 

(LET  ( (TEMP-SEV-EXPECT  (NTH  TEMP-COUNT  OOB-SEVERITY))  / ie  LL 
( TEMP-EXPECTANCY-SENSOR-DATA) 

) 

(COND  ((MEMBER  TEMP-SEV-EXPECT  1 ( LLL  LL  L) ) 

(SETQ  TEMP-EXPECTANCY-SENSOR-DATA  'LOWER)) 

((MEMBER  2MP-SEV-EXPECT  1  (H  HH  HHH)  ) 

(SETQ  TEMP-EXPECTANCY-SENSOR-DATA  'HIGHER)) 

(T 

(SETQ  TEMP-EXPECTANCY-SENSOR-DATA  NIL)) 

) 

/  / 

//Now  see  if  TEMP— ECPECTANCY-SENSOR-DATA  matches  with 
/,-the  scenarlo-expectancy-database-data.  If  yes  then  mark  as 
i /one  parameter  that  matches  the  expected  tendency 
/ / for  scenario  i . 

/if  data  matches  predicted 
(IF  (EQUAL  TEMP-EXPECTANCY-SENSOR-DATA 

SCENARIO-EXPECTANCY-DATABASE-DATA) 

/  /  Run  function  to  put  ‘'he  scenario  and  parameter 
//  which  matches  expectancy  in  its  database. 

(MARK-SCENARIO-PARAMETER-DATA  I  TEMPI— PARAMETER ) 

))>  ) 

))) 

) 

) 

) 

)  ,-end  match-scenario-tendency 

it  This  function  will  generate  the  default  list  for 
ii  scenario-data-match-list  there  are  12  scenarios  at  the  moment 

(DEFUN  GENERATE-LIST  () 

(SETQ  SCENARIO-DATA-MATCH-LIST 
(LIST  (LIST  1  NIL)  (LIST  2  NIL) 

(LIST  3  NIL)  (LIST  4  NIL) 

(LIST  5  NIL)  (LIST  6  NIL) 

(LIST  7  NIL)  (LIST  8  NIL) 

(LIST  9  NIL)  (LIST  10  NIL) 

(LIST  11  NIL)  (LIST  12  NIL))) 

) 
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ii  This  function  vill  add  the  scenario  and  its  parameter 
i i  which  agrees  with  its  expectancy  to  the  global  list 
i i  scenario— data-match-list . 

< DEFUN  HAK K-SCENXR I O- PARAMETER -DATA  ( SCENARIO-NUMBER  ASSOCIATED-PARAMETER) 

(COND  ((NULL  SCENARIO-DATA-MATCH-LIST) 

(GENERATE— LIST) 

)) 

(DOLIST  (DATA-RECORD  SCENAR IO-DATA-MATCH-LIST) 

(COND  ((EQUAL  SCENARIO-NUMBER  (CAR  DATA-RECORD)) 

(LET  ( (TEMPl-LIST  (CADR  DATA-RECORD)) 

> 

( SETQ  TEMPl-LIST 

(CONS  ASSOCIATED-PARAMETER  TEMPl-LIST)) 

(SETF  (CADR  DATA-RECORD)  /change  old  param  list  to 

TEMPl-LIST)  /the  new  consed  list 

)) 

))) 

///This  ends  the  checking  of  parameter/scenario  expectancies  and  updating 
ill  the  appropriate  data-lista. 

(DEFFLAVOR  SCENARIO-PARAMETER-MATCH  ( SCENARIO-NUM 

MATCH-PARAMETER) 

() 

: READABLE-INSTANCE-VARIABLES 

: writable-instance-variables 

: INITABLE-INSTANCE-VARIABLES) 


/ ;  j  ™ — -- — - - - 

/ / /  Determine  the  qualitative  match  for  the  lookahead  scenarios 
ill  eg  Major,  Minor,  etc. 


/ /  This  function  will  take  the  scenario-expectancy  list  and 
/ /  determine  the  number  of  parameters  that  are  expected  to 
it  match  under  ideal  conditions  for  each  scenario.  It  then  inserts 
it  the  results  in  the  global  list  parameters-per-scenario-expect . 

(DEFUN  MAKE-LIST-OP— NUM-P ARAMS-EXPECTED  {) 

(DOLIST  (J  SCENARIO— EXPECTANCY ) 

(LET*  ({TEMPI  (CAR  J)) 

(TEMPS  (CADR  J)) 

(TEMPI  (LENGTH  TEMPS)) 

) 

(SETQ  PARAMETERS-PER-SCENARIO-EXPECT 
(CONS  (LIST  TEMPI  TEMP 3 ) 

PARAMETERS-PER-SCENARIO-EXPECT) ) 

)) 

(SETQ  PARAMETERS-PER-SCENARIO-EXPECT 

(SORT  PARAMETERS-PER-SCENARIO-EXPECT  *'<  : KEY  I 'CAR) ) 

) 


/ ,-  Function  to  generate  the  raw  list  scenario-match-ratio 
/  /  set  up  for  13  scenarios  at  the  sxmtent  ■ 

(DEFUN  GENERATE-RATIO— LIST  () 

(SETQ  SCENARIO-RATIO-MATCH-LIST 
(LIST  (LIST  1)  (LIST  3) 

(LIST  3)  (LIST  4) 

(LIST  5)  (LIST  6) 

(LIST  7)  (LIST  8) 

(LIST  9)  (LIST  10) 

(LIST  11)  (LIST  12)) 

) 

) 
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/ ; 

Now  make  the  qualitative 

match  for  the  scenario. 

;  i 

At  the  moment  there  are  3 

levels  of  match. 

;  / 

scenario-match  ratio 

qualitative-match 

/ ; 

0.0  <-  x  <  0.3 

improbable 

1 1 

0.3  <-  x  <  0.75 

minor 

i  i 

0.75  <-  x  <-  1 

major 

;  ; 

;  ; 

the  results  will  then  be 
scenario-ratio-match-list 

put  into  another  list 

(DEFUN  SCENARIO-QUAL-MATCH  <) 

(SETO  SCENARIO-DATA-MATCH-LIST 

(SORT  SCENARIO-DATA-MATCH-LIST  *’<  : KEY  I'CAR)) 

(IF  (NULL  SCENARIO-RATIO-MATCH-LIST) 

(GENERATE-RATIO-LIST) ) 

( DOLIST  (I  SCENARIO-DATA-MATCH-LIST) 

(LET*  ( (TEMP-DATA-LENGTH  (LENGTH  (CADR  I))) 

(TEMP-EXPECT-LENGTH  assume  it  ia  sorted 

(CADR  (NTH  (1-  (CAR  I))  PARAMETERS-PER-SCENARIO-EXPECT ) ) ) 
/figure  percentage  match  with  expected 
(TEMP-RATIO  (/  TEMP-DATA-LENGTH  TEMP-EXPECT-LENGTH)) 

( TEMP— Q UAL -VALUE ) 

) 

/set  qualitative  match  value  for  the  scenario  under  evaluation 

(COND  ((<  TEMP-RATIO  0.3) 

(SETO  TEMP-OUAL-VALUE  ‘IMPROBABLE)) 

((<  TEMP-RATIO  0.75) 

(SETQ  TEMP-OUAL-VALUE  ’MINOR)) 

( (<-  TEMP-RATIO  1.0) 

(SETQ  TEMP-OUAL-VALUE  ‘MAJOR))) 

/modify  the  list  to  include  the  new  data  of  the  ratio  and  the 
/qualitative  value  of  the  match. 

(SETF  (NTH  (1-  (CAR  I))  SCENARIO-RATIO-MATCH-LIST) 

(APPEND  JNTH  (1-  (CAR  I))  SCENARIO-RATIO-MATCH-LIST) 

( , TEMP-RATIO  , TEMP-OUAL-VALUE ) ) ) 

)  /end  let* 

) 

) 

; , ,  —————————————————————————— 

///  Sort  the  scenarios  into  their  appropriate  list  depending  on 
/ / /  what  their  qualitative  values  are  for  the  scenario/parameter 
/ / /  matching . 

ii  This  function  will  create  three  new  global  lists: 

/ z  scenario-major 

/ z  scenario-minor 

/ /  scenario-improbable 

/ /  which  will  contain  all  the  scenario  • 1 s  and  are  sorted  with 

ii  the  largest  ratio'd  scenarios  first.  It  will  be  used  later 
ii  to  determine  parameter  priorities. 

/  / 

(DEFUN  SPLIT— INTO— MAJ— MINOR  () 

(DOLIST  (I  SCENARIO-RATIO-MATCH-LIST) 

(LET  ((TEMP-SCEN  (CAR  I)) 

(TEMP-RATIO  (NTH  1  I)) 

(TEMP-QUAL  (NTH  21)) 

) 

(COND  ((EQUAL  TEMP-QUAL  ’IMPROBABLE) 

(SETO  SCENARIO-IMPROBABLE  (CONS  (LIST  TEMP-SCEN  TEMP-RATIO) 

SCENARIO- IMPROBABLE) ) ) 

((EQUAL  TEMP-QUAL  'MINOR) 

(SETQ  SCENARIO-MINOR  (CONS  (LIST  TEMP-SCEN  TEMP-RATIO) 

SCENARIO-MINOR) ) ) 

((EQUAL  TEMP-QUAL  ’MAJOR) 

(SETQ  SCENARIO-MAJOR  (CONS  (LIST  TEMP-SCEN  TEMP-RATIO) 

SCENARIO-MAJOR) ) ) 

)  / end  cond 
)) 

(SETO  SCENARIO- IMPROBABLE  (SORT  SCENARIO-IMPROBABLE  *’>  .KEY  I ’CADR) 
SCENARIO-MINOR  (SORT  SCENARIO-MINOR  »’>  : KEY  I’CADR) 

SCENARIO-MAJOR  (SORT  SCENARIO-MAJOR  l’>  .-KEY  t’CADR)) 

)  /end  function 


///  Functions  to  determine  the  system's  Parameters  Priority 
til  It  will  dump  the  results  into  the  parameter's  database. 


ii  This  function  is  for  importing  the  parameter's  ranking  data  file. 
it  What  it  is  is  a  file  with  each  of  the  system  parameters/  and 
ii  the  ranking  of  importance  [1..10]  10  being  most  important/  for 
ii  all  the  given  combinations  of  scenarios.  For  example/  if  for 
ii  PZR-P  all  the  for  it  (1/  2,  3,  4)  all  had  a  major  qual.  match 
ii  value  (ie  all  the  parameters  matched  well  with  the  scenarios)/ 
ii  then  the  prioity  given  to  PZR-P  would  be  10,  since  all  data 
i ;  correlates  "perfectly"  with  the  expected  on  both  the  scenario 
ii  side,  and  the  parameter  side. 

; ; 


(DEFUN  MAKE-PARAMETER-EXPECTANCY  (INPUT-FILE) 

;  input  file  h: >srn>thesis>parameter— expect . data 
(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 
(WITH-OPEN-FILE  (PARAM-INPUT  INPUT-FILE 

:  DIRECTION  .-INPUT 
: CHARACTERS  T) 

/ ;  Note  in  the  data  file  the  whole  thing  is  one  big 
it  Lisp  form...  this  case  a  list. 


i  t 
1 1 
i  I 
I  I 
i 
1 
I 
I 

I  I 

I 

I 

I 

1 


The  set  up  of  parameter-expectancy  is  as  follows: 
(  (P*r-p  (  (10  (123  4)) 

<8  (2  3  4)) 


) 

(  (63)  ; for  the  hybrid  version 

(3  2) 

(1  1)>) 

etc  )  ) 

(pzr-1  <  (10  (3468) 

(6  (38) 

•  •  -  )) 

. . . .etc  . . . ) 


i  I 

( SETQ  parameter-expectancy 
(READ  PARAM-INPUT)) 

) 

)  ,-End  fun 


,- ;  This  function  initializes  the  list  parameter-ratio-match 

/ ; 

(DEFUN  GENERATE-PARAM-RATIO-HATCH-LIST  () 

(SETQ  PARAMETER-RATIO-MATCH 
(LIST  (LIST  'PZR-P  NIL)  (LIST  'PZR-L  NIL) 

(LIST  ' HL1— T  NIL)  (LIST  ' SG1-P  NIL) 

(LIST  ' SGI— L  NIL)  (LIST  'QNT-P  NIL) 

(LIST  ' SG2-P  NIL)  (LIST  ' SG2-L  NIL) 

(LIST  ' CH— T  NIL)) 

) 

) 


; ;  This  function  updates  the  list  parameter-ratio-data  and  inputs 
ii  the  lists  of  rank-10  scenarios,  major  seen.,  etc. 
ii  while  looping  through,  it  updates  upon  match  of  parameter  key 
ii  using  the  setf  function. 

(DEFUN  MARK-PARAMETER-RATIO-DATA  (PARAMETER  RATIO-LIST) 

(COND  ((NULL  PARAMETER-RATIO-MATCH) 

( GENERATE-P ARAM-R ATIO-MATCH-LI ST ) 

))  /end  cond 

(DOLIST  (DATA-RECORD  PARAMETER-RATIO-MATCH) 

(COND  ( ( EQUAL  PARAMETER  (CAR  DATA-RECORD)) 

(LET  ( (TEMP1-LIST) 

) 

(SETQ  TEMP1-LIST 

(APPEND  TEMP1-LIST  RATIO-LIST)) 

(SETF  (CADR  DATA-RECORD)  /change  old  param  list  to 

TEMPI— LIST)  / the  new  appended  list 

)) 

) 

) 


) 
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it  Nov  take  each  parameter  (eg  pxr-p]  and  compare  ita  expected 
/ ;  scenarios  with  the  scenarios  of  valid  matching  from 
11  scenario-ratio-match  data. 

ii  Put  the  results  in  parameter— ratio-match  database.  (Similar 
ii  to  scenario-ratio-match).  Ratio  ia  I  scenarios  that  are  good  / 
it  f  scenarios  expected  by  parameter-expectancy 
ii  This  is  much  like  the  Scanario-Qual -Match  function. 

(DEFUN  HAKE— PARAMETER— COMPARISON  () 

(GENRRATE-PARAM-RATIO-MATCH-LIST) 

( DOLXST  (I  OOB-PARAMETERS) 

( DOLIST  (K  PARAMETER-EXPECTANCY) 

(COND  ((EQUAL  (CAR  K)  I) 

(LET  ( ( TEMP- 10- SCAN  (CADR  (CAADR  K)>) 

(TEMP-SC-MAJ) 

(TEMP-SC— MIN) 

(TEMP-SC-IMP) 

(TEMP-LIST) 

) 

ii  loop  thru  the  rank  10  scenarios  and  compare  what  qual. 
ii  match  they  have.  Add  the  scenario  to  the  approp.  list. 

1 1 

(DOLIST  (J  TEMP— 10— SCAN) 

(DOLIST  (M  SCENARIO-MAJOR) 

(IF  (EQUAL  J  (CAR  M))  (SETQ  TEMP-SC-MAJ  (CONS  J  TEMP-SC-MAJ)) 

)) 

(DOLIST  (M  SCENARIO-MINOR) 

(IF  (EQUAL  J  (CAR  M) )  (SETQ  TEMP-SC-MIN  (CONS  J  TEMP-SC-MIN) ) 

)) 

)  ; end  doliat  j 

(SETQ  TEMP-LIST 

(LIST  (LIST  (LENGTH  TEMP-10-SCAN) ) 

TEMP-SC-MAJ 

TEMP-SC-MIN 

TEMP-SC-IMP)) 

; j  Update  the  list  parameter-ratio-match  using  setf  by  adding 
; i  in  the  values  in  temp-list  to  the  data  field  of  the  parameter 
ii  -ratio-match  list.  The  mark-parameter-ratio-data  function 
ii  performs  this  update. 

1 1 

(MARK-PARAMETER-RATIO-DATA  I  TEMP-LIST) 

)  i end  let 

) )  /end  cond 

)  /end  doliat  K 

)  /end  dolist  I 

/ /  Sorts  out  the  parameters  by  rank 
/ ; 

( MAKE-PARAMETER-RANKING ) 

)  /end 

ii  Nov,  that  the  lists  are  sorted,  DECA  vill  put  the  parameters 
i i  into  priority  according  to  the  conclusions  derived  from  the 

ii  data  thus  far. 

1 1 

(DEFUN  MAKE-PARAMETER-RANKING  () 

i i  Sort  thru  the  parameter-ratio-match  list 
(DOLIST  (I  PARAMETER-RATIO-MATCH) 

(LET  ( ( TEMP -FLAG -FOR -MATCH) 

(TEMP-PARAM  (CAR  I)) 

(TEMP-SCENARIOS  (RETRIEVE-SCENARIOS  I))  /do  not  vant  10-rank  in  it 

\i  note  that  temp-scenarios  contents  are  already  sorted. 
ii  So  they  are  ready  for  the  match  vlth  the  parameter-expectancy 
(DOLIST  (PARAM-BXPT  PARAMETER-EXPECTANCY) 

(COND  ((EQUAL  (CAR  PARAM-EXPT)  TEMP-PARAM) 

(LET  {(PARAMETER -TEMPLATE  (CADR  PARAM-EXPT))  ) 

(DOLIST  (J  PARAMETER-TEMPLATE) 

(LET  ((TEMP-RANK  (CAR  J)) 

(TEMP-RECORD  (CADR  J)) 

) 

(IF  (EQUAL  TEMP-SCENARIOS  TEMP-RECORD) 

(SETQ  TEMP-FLAG-FOR-MATCH  T 
PARAMETER-RANK-LIST 
(CONS  (LIST  TEMP-PARAM  TEMP-RANK) 
PARAMETER-RANK-LIST) ) 


)  )  )  ) 


/Code  for  the  hybrid  system. 

/Nov  if  DECA  hasn't  received  a  rank  yet,  (ie  fall  at  the  most 
/significant  matches),  then  the  function  switches  to  a  mode 
/which  isn't  combinatorially  explosive,  (not  n  factorial 
/combinations  to  search  thru  a  impossible  for  real  time.] 

/The  hybrid  looses  some  of  the  subtle  knowledge  of  parameter 
/scenario  interrelationships,  but  not  all.  It  only  covers  the 
/most  significant  ones  as  dictated  by  the  knowledge  base. 

/  To  do  the  next  part  use  a  third  sublist  in 
/parameter-expectancy  which  contains,  a  rank  x  and  the  number 
/of  scenarios  needed  to  fit  ( ie  3  of  the  7  in  10-rank).  This 
/eliminates  the  need  to  search  all  the  combinations. 


<COND  ((NULL  TEMP-FLAG-FOR-MATCH) 

(LET  ( (SCEN-NUM-TEMPLATE  (CADDR  PARAM-EXPT) ) ) 

(DOLIST  (K  SCEN-NUM-TEMPLATE) 

(LET  ((TEMP-RANK  (CAR  X)) 

(TEMP-SC-NUM  (CADR  K) ) ) 

(IF  (EQUAL  TEMP-SC-NUM  (LENGTH  TEMP-SCENARIOS)) 

( SETQ  PARAMETER-RANK-LIST 

(CONS  (LIST  TEMP-PARAM  TEMP-RANK) 
PARAMETER-RANK-LIST) ) ) 

))) 

/  Just  in  case  there  vas  not  any  match  via  hybrid 
(IF  (AND  (MEMBER  TEMP-PARAM  OOB-PARAMETERS ) 

(NOT  (EQUAL  (CAAR  PARAMETER-RANK-LIST) 

TEMP-PARAM) ) ) 

(SETQ  PARAMETER-RANK-LIST 

(CONS  (LIST  TEMP-PARAM  1)  PARAMETER-RANK-LIST))) 

)) 


)  ) 

) 

/ /  At  this  point  the  oob-parameters  have  all  been  assigned  a 
//  rank.  Now  DECA  can  assign  the  priority  according  to  the  rank. 

; /  In  the  list  parameter-rank-list  it  contains  a  bunch  of  conses  of 
it  (parameter  .  rank).  Nov  sort  thru  these  sublists  and  put  in 
ii  descending  order  according  to  rank. 

(SETQ  PARAMETER-RANK-LIST  (SORT  PARAMETER -RANK-LIST  »'>  : KEY  » ' CADR ) ) 


)  /end  make-parameter-ranking 


it  Used  to  get  all  the  scenarios  of  the  parameter  under  consideration. 

(DEFUN  RETRIEVE-SCENARIOS  (I) 

( LET*  ((TEMP-DATA  ( CDADR  I)) 

(TEMP— MAJ  (FIRST  TEMP-DATA)) 

(TEMP— MIN  (SECOND  TEMP-DATA)) 

(TEMP-IMP  (THIRD  TEMP-DATA)) 

(TEMP-ALL) 

) 

(SETQ  TEMP-ALL 

(SORT  (APPEND  TEMP “MAJ  TEMP-MIN  TEMP-IMP)  »'<)) 

) 

) 


i i i  Qualitatively  refine  parameter  sort 

it  Using  the  list  parameter-rank-list  DECA  will  see  if  the  rank  is 
ii  is  appropriate  given  the  levels  of  confidence  in  the  likelyhood 
it  of  the  scenario  occurring. 

/ 1 

(DEFUN  REFINE-PARAMETER-RANK-TOP  () 

(SETQ  PARAMETER-RANK-LIST 

( REFINE-PARAMETER-RANK  PARAMETER-RANK-LIST) ) 

(SETQ  PARAMETER-RANK-LIST 

(SORT  PARAMETER-RANX-LIST  *'>  : KEY  I • GET-RANK-INDEX) ) 

) 


(DEFUN  GET-RANK- INDEX  (X) 
(CAR  (LAST  X)) 

) 
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;/  Refine-parameter-rank  function  will  evaluate  the  list  of 
i i  parameters  and  their  associated  ranks  and 
/  /  of  parameters  which  have  the  sane  rank  by 
; ;  severity .  The  worse  the  severity  the  more 
/ /  the  parameter  for  a  given  rank . 

(DEPUN  REPINE-PARAMETER-RANK  (RANH  ^OPTIONAL 
{LET  ((TEMPI  (CAR  RANK)) 

(TEMPS  (CADR  RANK)) 

(TEMP 3  (CDDR  RANK)) 

) 

(COND  ((NULL  TEMPS) 

(SETQ  NEW— LIST  (CONS  TEMPI  NEW-LIST)) 

(SETQ  NEW-LIST  (REVERSE  NEW-LIST)) 

NEW-LIST) 

(T  (COND  ((EQUAL  (LAST  TEMPI)  (LAST  TEMPS)) 

(SETQ  TEMPI 

(CONS  (CAR  TEMPS)  TEMPI)) 

(SETQ  RANK 

(CONS  TEMPI  TEMP 3 ) ) 

;  /  (  FORMAT  T  "Ta  "RANK) 

(REFINE-PARAMETER-RANK  RANK  NEW-LIST)) 

;  Now  if  S  ranks  not  the  same. 

(T 

(SETQ  NEW-LIST  (CONS  TEMPI  NEW-LIST) 

RANK  (CONS  TEMPS  TEMP 3 ) ) 

;; (FORMAT  T  new-list  "a") 

;; (FORMAT  T  ““%  ”a"RANK) 
(REFINE-PARAMETER-RANK  RANK  NEW-LIST)) 

)  ;end  cond 

/end  cond 


refines  the  ranking 
checking  their 
priority  given  to 


(NEW-LIST  NIL)) 


; ;  Now  have  the  new  list  of  parameters  which  are  grouped  by  conmon 
;;  rank.  In  order-multiple  it  will  loop  through  the  list  to  see  if 
it  length  is  >  3  (ie  more  than  1  pa ram  with  a  given  rank).  It  then 
li  calls  change-order  which  will  compare  these  rank's  severity  and 
;;  order  them  accordingly.  Then  the  function  loose-parentheses  is 
//  called  to  clean  up  the  list  and  return  back  to  the  original  list 
;;  except  that  the  parameters  have  been  refined  for  each  rank. 

/  i 

(DEFUN  ORDER-MULTIPLES  () 

( DOLIST  (I  PARAMETER-RANK-LIST) 

(COND  ((>  (LENGTH  I)  2) 

(LET  ((TEMP-1  (CHANGE-ORDER  I>) 

) 

(SETQ  PARAMETER-RANK-LIST  /don't  use  setf  here 

(SUBST  TEMP-1  I  PARAMETER-RANK-LIST)) 

; ; ( SETF  I  TEMP-1) 

))) 

) 

/  remove  redundant  ( ) ' a 
(SETQ  PARAMETER-RANK-LIST 
(LOOSE-PARENTHESES  PARAMETER-RANK-LIST) ) 

) 

(DEFUN  CHANGE-ORDER  (I) 

(LET  ((TEMP-LIST  ( EL: FIRSTN  (1-  (LENGTH  I))  I)) 

(TEMP-RANK  (CAR  (LAST  I))) 

) 

(DOLIST  (J  TEMP-LIST) 

( LET*  ((TEMP-PLACE  (-  (LENGTH  OOB-PARAMETERS ) 

(LENGTH  (MEMBER  J  OOB-PARAMETERS)))) 
(TEMP-SEVERITY  (NTH  TEMP-PLACE  OOB-SEVERITY) ) 

> 

(COND  ((OR  (EQUAL  TEMP-SEVERITY  ' LLL) 

(EQUAL  TEMP-SEVERITY  ' HHH ) ) 

(SETQ  TEMP-LIST  (SUBST  (LIST  J  3)  J  TEMP-LIST))) 

/;  Old  (SETF  J  (LIST  J  3))) 

((OR  (EQUAL  TEMP-SEVERITY  'LL) 

(EQUAL  TEMP-SEVERITY  'HH)> 

(SETQ  TEMP-LIST  (SUBST  (LIST  J  3)  J  TEMP-LIST))) 

({OR  (EQUAL  TEMP-SEVERITY  'L) 

(EQUAL  TEMP-SEVERITY  'H)) 

(SETQ  TEMP-LIST  (SUBST  (LIST  J  1)  J  TEMP-LIST))) 

) 

))  /end  doliat 
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(SETQ  TEMP-LIST  (SORT  TEMP-LIST  *•>  : KEY  I'CADR)) 

(DOH ST  <K  TEMP-LIST) 

(SETF  (CAOR  K)  TEMP-RANK) 

) 

/return  the  nev  and  improved  sublist  to  function  order-multiple . 
TEMP- LI ST 
) 


11  Now  the  variable  would  have  the  following  format: 
ii  ((a  10)  <<d  9) <b  9) (c  9))  (e  3)...) 

1 1  Need  to  remove  the  redundant  ( )  on  parame  w/same  ranks 

;  ; 

(DEFUN  LOOSE-PARENTHESES  (RANK) 

(LET  ((TEMP-LIST)) 

(DOLIST  (I  RANK) 

(COND  (( LISTP  (CAR  I)) 

(DOLIST  (J  I) 

(SETQ  TEMP-LIST  (CONS  J  TEMP-LIST)) 


(SETQ  TEMP-LIST  (CONS  I  TEMP-LIST)) 

)> 

) 

(SETQ  RANK  (REVERSE  TEMP-LIST)) 

) 

RANK 

) 


i t i  Qualitatively  sort  scenarios 


;;  Set  up  the  list  possible-scenario-for-situatlon,  which  will 
; i  contain  the  scenarios  which  have  a  reasonable  possibility  to 
ii  be  the  actual  scenario,  (ie  maj  or  min  scenarios).  More 
i ;  refinment  may  be  necessary  if  there  is  less  than  great  match 

ii  (agreement)  with  params  and  scenarios. 

(DEFUN  PUT- SCENARIOS— TOGETHER  () 

(SETQ  POSSIBLE— SCENARIO— FOR— SITUATION 
(APPEND  SCENARIO-MAJOR  SCENARIO-MINOR)) 

(SETQ  POSSIBLE— SCENARIO— FOR— SITUATION 

(SORT  POSSIBLE— SCENARIO— FOR— SITUATION  #’>  : KEY  I'CADR)) 

) 

i i i  Run  context  solution  searches  and  output  results , 

;  ii  1  -  Scenario 

ill  2  -  Parameters  and  their  priority 

ill  3  -  Suggested  action  to  alleviate  the  situation 

1 1 1 


; /  Read  in  the  data  from  disk  for  the  scenario  number  and  its 
ii  associated  description. 

ii  file  -  h :  >  sm>  thesis  >scenario— descriptions .  data 

/  l 

(DEFUN  MAKE-SCENARIO-DESCRIPTION  (INPUT-FILE) 

(SETQ  INPUT-FILE  ( FS : PARSE-PATHNAME  INPUT-FILE)) 
(WITH-OPBN-FILE  (DESCRIPTION-INPUT  INPUT-FILE 

: DIRECTION  : INPUT 
••CHARACTERS  T) 

ii  Note  in  the  data  file  the  whole  thing  is  one  big 
it  Lisp  form...  this  case  a  list. 

/  / 

(SETQ  SCENARIO-DESCRIPTION 
(READ  DESCRIPTION-INPUT)) 

) 

)  / End  fun 
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; ;  This  function  will  control  all  the  output  to  the  user 

/ / 

( DEPUN  OUTPUT— CONTROL  () 

(COND  ((NULL  SCENARIO-MAJOR) 

(FORMAT  T  "”%DECA '  a  conclusions  for  ayatesi  time:  "a  ~%"  SYS-TIME) 
(OUTPUT-RESULTS-WITHOUT-SCENARIO) 

(FORMAT  T  “_»End  of  data  evaluation  for  system  time:  "a  **“  SYS-TIME) 

> 

(T 

(FORMAT  T  *'“%DECA 1  a  concluaions  for  system  time:  “a  SYS-TIME) 

(OUTPUT-RESULTS-WITH-SCENARIO) 

(FORMAT  T  *,_%End  of  data  evaluation  for  system  time:  "a  "*'•  SYS-TIME) 

)) 

> 

(DEFUN  OUTPUT-RESULTS -WITHOUT- SCENARIO  () 

/first  the  scenario 
; output 

(FORMAT  T  "“%  No  scenario  selected,  not  confident  enough.  *%'') 

(FORMAT  T  "“%  The  parameter  and  priorities  are  as  follows:  "2%") 
(DOLIST  (I  PARAMETER-RANK-LIST) 

(LET  ( (PARAM  (CAR  I)) 

( RANK  ( CADR  I ) ) 

) 

(FORMAT  T  "  3T  a  16T  a  V  PARAM  RANK) 

)) 

//(WRITE  PARAMETER-RANK-LIST  : PRETTY  :ALIST) 

(FORMAT  T  "~2%  Scenarios  that  were  considered  as  possible  choices  ~%“) 
(FORMAT  T  "  but  not  selected  are:  'at") 

(FORMAT  T  “  Scenario  Ratio  Description  ”3%M) 

(DOLIST  ( SCENARIO— NUM  POSSIBLE-SCBNARIO-FOR-SITUATION) 

(LET  ( (TEMP-SCEN-NUM  (CAR  SCENARIO-NUM) ) 

(TEMP-RATIO  (CADR  SCENARIO-NUM)) 

(TEMP-DESCRIPTION  ) 

) 

(DOLIST  (J  SCENARIO-DESCRIPTION) 

(IF  (EQUAL  (CAR  J)  TEMP-SCEN-NUM) 

(SETQ  TEMP-DESCRIPTION  (CADR  J))) 

) 

(FORMAT  T  "~3T  *a  “13T“A  "20T  *a**“ 

TEMP-SCEN-NUM 

TEMP-RATIO 

TEMP-DESCRIPTION) 

)) 

(FORMAT  T  "  21") 

//(WRITE  POSSIBLE— SCENARIO— FOR— SITUATION  .PRETTY  :ALIST) 


(DEFUN  OUTPUT-RESULTS-WITH-SCENARIO  () 

/ first  the  scenario 

(LET  ((TEMP-SCENARIO-SPECIFICS  ) 

) 

/ output 

(FORMAT  T  Scenario  selected  is/  ”%") 

(SETQ  TEMP-SCENARIO-SPECIFICS  (GET-GUESS) ) 

(FORMAT  T  “  scenario  Number  "a  (FIRST  TEMP-SCENARIO-SPECIFICS)) 

(FORMAT  T  "  Scenario  Description  "d  ’»"  (LAST  TEMP-SCENARIO-SPBCIFICS) ) 
(FORMAT  T  M  Confidence  "a  2»"  (SECOND  TEMP-SCENARIO-SPECIFICS) ) 
(FORMAT  T  "“%  The  parameter  and  priorities  are  as  follows:  ~2%") 

(DOLIST  (I  PARAMETER-RANK-LIST) 

(LET  ((PARAM  (CAR  I)) 

(RANK  (CADR  I)) 

) 

(FORMAT  T  "  3T  a  16T  a  »"  PARAM  RANK) 

)) 

//(WRITE  PARAMETER-RANK-LIST  : PRETTY  :ALIST) 

(FORMAT  T  "*2»  Scenarios  that  were  considered  as  possible  choices  *%**) 
(FORMAT  T  "  but  not  selected  are:  *2»") 

(FORMAT  T  "  scenario  Ratio  Description  "2*") 

(DOLIST  (SCENARIO-NUM  POSSIBLE-SCENARIO-POR-SITUATION) 

(LET  ( (TEMP-SCEN-NUM  (CAR  SCENARIO-NUM) ) 

(TEMP-RATIO  (CADR  SCENARIO-NUM)) 

(TEMP-DESCRIPTION  ) 

) 

(DOLIST  (J  SCENARIO-DESCRIPTION) 

(IF  (EQUAL  (CAR  J)  TEMP-SCEN-NUM) 

(SETQ  TEMP-DESCRIPTION  (CADR  J))> 

) 
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(FORMAT  T  "”3T  *a  “13T'A  "20T  'aT 
TEMP-SCEN-NUM 
TEMP-RATIO 
TEMP-DESCRIPTION) 

)) 

(FORMAT  T  ""2*"  ) 

/(WRITE  (CDR  POSSIBLE— SCENARIO— FOR -SITUATION)  : PRETTY  ;ALIST) 

) 

) 

{ DEFUN  GET-GUESS  () 

(LET  < (TEMP-SCENARIO-INFO) 

(TEMP-NUMBER) 

(TEMP-DESCRIPTION) ) 

(SETQ  TEMP-SCENARIO-INFO  (CAR  POSSIBLE-SCENARIO-FOR-SITUATION)  ;eg  (I  0.75) 
TEMP-NUMBER  (CAR  TEMP-SCENARIO- INFO) ) 

( DOLIST  (I  SCENARIO-DESCRIPTION) 

(IF  (EQUAL  (CAR  I)  TEMP-NUMBER) 

(SETQ  TEMP-DESCRIPTION  (CADR  I))) 

) 

/return  the  results 

(APPEND  TEMP-SCENARIO-INFO  (LIST  TEMP-DESCRIPTION)) 

> 


lit  Function  for  resetting  variables  for  each  loop 


(DEFUN  RESET— AND— REGENERATE -GLOB ALS  () 


I 

(SETQ  OOB-PARAMETERS 
OOB-SEVERITY  NIL 

OOB-PARAMETERS-VALUBS  NIL 

LOOKAHEAD-SCENARIOS  NIL 

PARAMETERS-PER-SCENARIO— EXPECT  NIL 
SCENARIO-MAJOR  NIL 

SCENARIO-MINOR  NIL 

SCENARIO-IMPROBABLE  NIL 

PARAMETER-RANK-LIST  NIL 


POSSIBLE— SCENARIO— FOR— SITUATION  NIL) 

( GENERATE— LIST  ) 

( GENERATE— RATIO— LI ST ) 

(GENERATE— PARAM— RATIO— MATCH— LIST) 

)  /end  reset... 


NIL 


/  SCENARIO— DATA-MATCH— LIST 
/  SCENARIO-RATIO-MATCH-LIST 
I  PARAMETER-RATIO-MATCH 


(DEFUN  RESET- AT-END-OF-LOOP  () 

(SETQ  SDB-LIST  NIL 

SETPOINT-DATA  NIL 

SCENARIO-LIST  NIL 

SCENARIO-DESCRIPTION  NIL 
PARAMETER-EXPECTANCY  NIL 
SCENARIO-EXPECTANCY  NIL) 

) 

;  /  / 

///MAIN-LOOP  FOR  THE  DECA  SYSTEM 

/  /  ; 

(DEFUN  DECA  ( ) 

( RESET- AT-END-OF-LOOP ) 
ii  setup  sensor-data  from  file 

( BRING— IN— SYSTEM— DATA  "hi >srn>thesis>sensor . data” ) 

/ /  setup  setpoint  database 

(MAKE-SETPOINT-DATABASE  "h : >sra>theais>setpoint . data" ) 

/ ;  setup  paraneter/scenario  database 

( MAXE-PARAMETER-SCENAR IO-DAT ABASE  "h : >sm>thesis>scenario . data” ) 

( MAKE-SCENARIO— EXPECTANCY  "h: >sm>thesis>scenario-tendency . data" ) 

(MAKE-PARAMETER-EXPECTANCY  "h : >srn>thesis>paraaeter-expect . data" ) 

( MAKE-SCENAR IO-DESCR IPTION  "h : >srn> thesis >scenario-descript ions . data" ) 
/ ;  now  begin  to  loop  for  each  tine  step  that  deca  is  evaluating 

(IF  (NOT  (EQUAL  SENSOR-DATA  NIL))  /check  if  out  of  data 


i  t  dov  Mka  a  run  through  OBCA  for  the  time  record  sensor-record 
( DO LI ST  (1  SENSOR-DATA) 

(SETQ  SYS-TIME  (CAR  I)) 

(SETO  SENSOR-RECORD  (CADR  I)> 

(FORMAT  T  “"% Intermediate  parameters  for  system  time:  “a  "%"  SYS-TIME) 
(FORMAT  T  "'"ASenaor- record  SENSOR-RECORD) 

( RBSBT-AND-REGENERATE-GLOBALS  > 

(COMPARE-SENSOR-DATA  SENSOR-RECORD  SDB-LXST)  ;_seta  oob 

(FORMAT  T  "Oob-parameters  "a"IOob-parameters-values  "a"%Oob-severlty  ~A”2% 
OOB-PARAMETERS  OOB-PARAMETERS-VALUES  OOB-SEVERITY) 

(GET-SCENARIOS  OOB-PARAMETERS) 

(FORMAT  T  "Lookahead-scenarios  “a"2%“  LOOKAHEAD-SCENARIOS) 

/ ;  match  tendencies  with  expected 
( MATCH -SCBNAR IO-TENDENC Y ) 

(FORMAT  T  " Scenario-da ta-match-list  ■a“2*“  SCBNAR IO-DATA-MATCH-LI ST ) 
(MAKE-LIST-OF-NOM-PARAMS-EXPECTED) 

(FORMAT  T  "Parameters-per-scenario-expect  “a“2%" 

PARAMETERS-PBR— SCENARIO-EYPECT) 

( SCBNAR IO-QUAL-MATCH ) 

(FORMAT  T  "Scecario-ratio-match-list  _a"2»"  SCBNAR 10— RATIO-MATCH— LIST ) 

( SPLIT— INTO-MAJ  MINOR) 

(FORMAT  T  "Scenario-major  ”a"%Scenario-minor  "a"»Scenario-improbabXe  "a"2% 
SCENARIO-MAJOR  SCENARIO-MINOR  SCENARIO- IMPROBABLE) 

( MAKE-PAR AMETER-COMP AR I SON ) 

(FORMAT  T  “Parameter-ratio-match  "a”%Parameter-rank-liat  “a~2*“ 
PARAMETER-RATIO-MATCH  PARAMETER-RANK-LIST) 

( REFINE-PARAMETER-RANK-TOP ) 

(FORMAT  T  "Parameter-rank-list  “A“2»“  PARAMETER-RANK-LIST) 

( ORDER-MULTI PLES ) 

(FORMAT  T  "Parameter-rank-list  'A'2t“  PARAMETER-RANK-LIST) 

( PUT-SCENARIOS -TOG ETHER ) 

(FORMAT  T  "Possible-scenarios-for-situation  “a"2*M 
POSSIBLE— SCENARIO— FOR— SITUATION) 

( OUTPUT-CONTROL ) 

)  /end  of  DO 

) 

)  /end  DECA 


; / ;  Function  for  manual  run 


(DEFUN  MANUAL  () 

( RESET- AT-BND-OF-LOOP ) 

( BRING— IN— SYSTEM-DATA  "h : >srn> thesis >senaor . data" ) 

( MAKE-SETPO I NT-DAT ABASE  "h: >om > thesis >setpoint . data " ) 
(MAKE-PARAMETER-SCENARIO-DATABASE  "h: >srn>thesis>scenario . data" ) 
(MAKE-SCENARIO-EXPECTANCY  “h: >sm>thesis>scenario-tendency . data" ) 
(MAKE-PARAMETER-EXPECTANCY  “h: >srn> thesis >parameter-expect . data" ) 
(MAKE-SCENARIO-DESCRIPTION  “h : >srn > thesis >scenarlo-descriptions . data “ ) 
; ;  initialize  some  global  parameters  before  the  loops 
(SETQ  SYS-TIME  (CAAR  SENSOR-DATA) 

SENSOR-RECORD  (CADAR  SENSOR-DATA) 

SENSOR-DATA  (CDR  SENSOR-DATA)) 

<  RESET— AND-REGENERATE-GLOBALS  ) 

(TIME  (LET  () 

(COMPARE-SENSOR-DATA  SENSOR-RECORD  SDB-LIST)  /sets  oob 
(GET-SCENARIOS  OOB-PARAMETERS) 

( MATCH-SCEN AR IO-TENDENC Y ) 

(MAKE-L I ST-OF-NUM-P  ARAMS -EXPECTED) 

( SCENARIO— QUAL -MATCH ) 

(SPLIT— INTO-MAJ -MINOR) 

( MAKE-PAR AMETER-COMP ARI SON ) 

( REFINE-PAR AMBTER-RANK-TOP ) 

(ORDER-MULTIPLES) 

( PUT— SCENARIOS— TOGETHER ) 

))  /end  time 

( OUTPUT-CONTROL ) 

ii  Reset  the  parameters  for  next  time  step. 

( RESET- AT-END-OF-LOOP)  /since  manual  loop 

)  /end  manual 


ill  Function*  for  ouputting  the  runs  to  disk  files 
(DEFUN  DEC A- PILE -OUTPUT  () 

( SETQ  OUTPUT- FILE-NAME  "h :  >srn>thesis>ruatime .  output" ) 

( RESET- AT- END-OF- LOOP ) 
ii  setup  data  from  file 

(BRING-IN-SYSTEM-DATA  “h : >sm> thesis >aensor . data” ) 

( MAKE-SETPOINT-DATABASE  ”h : >sm > thesis > setpoint . data “ ) 
(MAKE-PARAMETER-SCENARIO-DATABASE  "h: >srn > thesis >scenario . data" ) 

( MAKE- SCENARIO- EXPECTANCY  "h: >srn > thesis > scenario-tendency . data " ) 
(MAKE-PARAMETER-EXPECTANCY  “h:  >srn> thesis) par ameter-expect .  data"  ) 
(MAKE-SCENARIO-DESCRIPTION  "h: >sm> thesis) scenario-descriptions . data" ) 

(SETQ  OUTPUT-FILE-NAME  ( FS : PARSE-PATHNAME  OUTPUT-FILE-NAME)) 

; ;  now  begin  to  loop  for  jach  time  step  that  decs  is  evaluating 

/ / 

(IF  (NOT  (EQUAL  SENSOR-DATA  NIL))  ; check  if  out  of  data 

; take  return  out? 

(WITH-OPEN-FILE  (FILE-SPEC  OUTPUT-FILE-NAME 
[DIRECTION  [OUTPUT 
[CHARACTERS  T) 

; ;  now  make  a  run  through  DECA  for  the  time  record  sensor-record 
(DOLIST  (I  SENSOR-DATA) 

(SETQ  SYS-TIME  (CAR  I)) 

(SETQ  SENSOR-RECORD  (CADR  1)) 

(FORMAT  file-spec 

“~4 Intermediate  parameters  for  system  time[  ~a  ”t "  SYS-TIME) 
(FORMAT  file-spec  "*% Sensor-record  "a-*"  SENSOR-RECORD) 

( RESET-AND-REGENERATE-GLOBALS ) 

(COMPARE-SENSOR-DATA  SENSOR-RECORD  SDB-LIST)  / sets  oob 
(FORMAT  file-spec 

"Oob-parameters  “a“%Oob-parameters-values  “a“»Oob-severity  “A“a%" 
OOB-PARAMETERS  OOB-PAR AMETERS-VALUES  OOB-SEVERITY) 

(GET-SCENARIOS  OOB-PARAMETERS) 

(FORMAT  file-spec  "Lookahead-scenarios  "a^a*"  LOOKAHEAD-SCENARIOS) 
(MATCH-SCENARIO-TENDENCY) 

(FORMAT  file-spec 

“Scenario-data-match-iist  ■’a‘'2%"  SCENARIO-DATA— MATCH— LI  ST ) 

(  MAKE— LIST— OF-NUM-P  AR  AMS-EXPECTED  > 

(FORMAT  file-spec  “Parametera-per-scenario-expect  ~a~3% " 

PARAMETERS— PBR-SCENARIO— EXPECT) 

( SCENAR IO-QUAL-MATCH ) 

(FORMAT  file-spec 

"Scenario-ratio-match-list  "a'i*"  SCENARIO-RATIO-MATCH-LIST) 

( SPLIT— INTO— MAJ— MINOR ) 

(FORMAT  file-spec 

"Scenario-major  ”a"%Scenario-minor  ~r ”%Scenario- improbable  -a-a%" 
SCENARIO-MAJOR  SCENARIO-MINOR  SCENARIO-IMPROBABLE) 

( MAKE-PARAMETER-COMPARISON ) 

(FORMAT  file-spec 

“Parameter-ratio-match  "a”»P*rameter-rank-list 
PARAMETER-RATIO-MATCH  PARAMETER-RANK-LIST) 

( REFINE-PARAMETER-RANK -TOP ) 

(FORMAT  file-spec  "Parameter- rank-list  “A“2%"  PARAMETER-RANK-LIST) 

( ORDER-MULTIPLES ) 

(FORMAT  file-spec  “Parameter-rank-list  “A”2%“  PARAMETER-RANK-LIST) 

( PUT— SCENARIOS— TOGETHER ) 

(FORMAT  file-spec  "Possible-scenarios-for-situation  "a"a*" 
POSSIBLB-SCENARIO-FOR-SITUATION) 

( OUTPUT-CONTROL-TO-FILE ) 

) 


> 

;end  DECA 


) 


/end  of  DOLIST 
/end  of  with-open-f ile 
/end  if 
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/;  This  function  will  control  all  the  output  to  the  disk  file 

I  / 

(DEFUN  OUTPUT-CONTROL-TO-FILE  () 

(COND  ((NOLL  SCENARIO-MAJOR) 

(FORMAT  file-spec 

""tDBCA's  conclusions  for  system  time:  “a  "%"  SYS-TIME) 

( OUTPUT-RESULTS-WITHOUT-SCENAR IO-TO-PILE ) 

(FORMAT  file-spec 

•*"»End  of  data  evaluation  for  system  time:  *a  *»“’  SYS-TIME) 

) 

(T 

(FORMAT  file-spec 

"■%DECA'a  conclusions  for  system  time:  "a  SYS-TIME) 

(OUTPUT-RESULTS-WITH-SCENARIO-TO-FILE) 

(FORMAT  file-spec 

“"%End  of  data  evaluation  for  system  time.-  ”a  “%"  SYS-TIME) 


(DEFON  OUTPUT— RESULTS— WITHOUT— SC ENARIO-TO— FILE  () 
i first  the  scenario 
/output 

(FORMAT  file-spec  No  scenario  selected,  not  confident  enough.  “*“> 
(FORMAT  file-spec  “-%  The  parameter  and  priorities  are  as  follows:  "2%") 
(DOLIST  (I  PARAMETER-RANK-LIST) 

(LET  ((PARAM  (CAR  I)) 

(RANK  (CADR  I)) 

) 

(FORMAT  file-spec  “*3T*a  "16T'a  V  PARAM  RANK) 

)) 

//{WRITE  PARAMETER-RANK-LIST  : PRETTY  lALIST) 

(FORMAT  file-spec 

“*2%  Scenarios  that  were  considered  as  possible  choices  but  not'%") 
(FORMAT  file-spec  "  selected  are:  ~2\“) 

(FORMAT  file-spec  "  Scenario  Ratio  Description  ”2%“ ) 

(DOLIST  (SCENARIO— NUM  POSSIBLE-SCENARIO-FOR-SITUATION) 

(LET  { (TEMP-SCEN-NUM  (CAR  SCENARIO-NUM) ) 

(TEMP-RATIO  (CADR  SCENARIO-NUM)) 

(TEMP-DESCRIPTION  ) 

) 

(DOLIST  (J  SCENARIO-DESCRIPTION) 

(IF  (EQUAL  (CAR  J)  TEMP-SCEN-NUM) 

(SETQ  TEMP-DESCRIPTION  (CADR  J))) 

)  .... 

(FORMAT  file-spec  "_3T  a  13T  A  *20T  'a  %” 

TEMP-SCEN-NUM 

TEMP-RATIO 

TEMP-DESCRIPTION) 

)) 

(FORMAT  file-spec  M  It") 

//(WRITE  POSSI BLE— SCENAR IO-FOR-S ITUATION  : PRETTY  :ALIST) 


{ DEFUN  OUTPUT-RBSULTS-WITH-SCENARIO-TO— FILE  () 

/first  the  scenario 

(LET  ((TEMP-SCENARIO-SPECIFICS  ) 

) 

; Output 

(FORMAT  file-spec  "*»  Scenario  selected  is,-  ’I") 

(SETQ  TEMP-SCENARIO-SPECIFICS  (GET-GUES' ) ) 

(FORMAT  file-spec  "  Scenario  Number  *a  *»"  (FIRST  TEMP-SCENARIO-SPECIFICS) ) 
(FORMAT  file-spec  "  Scenario  Description  *d  »"  (LAST  TEMP-SCENARIO-SPECIFICS)) 
(FORMAT  file-spec  ■  Confidence  *a  *2%"  (SECOND  TEMP-SCBNARIO-SPECIFICS) > 
(FORMAT  file-spec  *“%  The  parameter  and  priorities  are  as  follows:  "2%") 
(DOLIST  (I  PARAMETER-RANK-LIST) 

(LET  ((PARAM  (CAR  I)) 

<  RANK  ( CADR  I  )  ) 

>  .  . 

(FORMAT  file-spec  "  3T  a  16T  a  »■  PARAM  RANK) 

>> 

//(WRITE  PARAMETER-RANK-LIST  : PRETTY  :ALIST) 

(FORMAT  file-spec 

'*'2%  Scenarios  that  were  considered  as  possible  choices  but  not  %"> 

(FORMAT  file-spec  “  selected  are:  *2%*) 

(FORMAT  file-apec  "  Scenario  Ratio  Description  ”2*H) 

(DOLIST  (SCENARIO-NUM  POSSIBLE-SCBNARIO-POR-SITUATION) 

(LET  {(TEMP-SCEN-NUM  (CAR  SCENARIO-NUM)) 

(TEMP-RATIO  (CADR  SCENARIO-NUM)) 

(TEMP-DESCRIPTION  ) 
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(DOLIST  (J  SCENARIO-DESCRIPTION) 

(IP  (EQUAL  (CAR  J)  TEMP-SCEN-NUM) 

(SETQ  TEMP-DESCRIPTION  (CADR  J))) 

) 

(FORMAT  file-spec  ""3T  ”a  “13T”A  '20T  "a**" 

TEMP-SCEN-NUM 
TEMP-RATIO 
TEMP-DESCRIPTION) 

)) 

(FORMAT  file-spec  H"2%H  ) 

/(WRITE  ( CDR  POSSIBLE-SCENARIO-FOR-SITUATION)  : PRETTY  :ALIST) 


End  of  DECA  Kernel 


